allow normal user to launch root GUI applications

Firstly, let me admit that I normally use Xsane for my scanning, so I am guessing a little here:

1) Use the setuid bit (https://secure.wikimedia.org/wikipedia/en/wiki/Setuid) and set it for the simple scan binary , or
2) Add your wife's account to the "scanner" group

Let me tell you what I did.

I used - chmod a-rwx simple-scan
it listed the following - -rwxrwxrwx 1 root root 121532 2010-10-22 09:00 simple-scan

I assume that that gave everyone the privilege to run the scanner.

When I logged back into my wifes account it still wont allow her to run it without the terminal. Typing it into the terminal - simple-scan - works fine. But I want to keep things simple for her.

I don't have a scanner group. Do I need to create one but then I may as well use another group we both belong to.

Much appreciate your help.

Jacques

a-rwx would remove privileges, not add them, I assume you meant +rwx.

Anyway, have another look at the SUID bit; it lets any user running the binary with the setuid bit gain root privs for that app only.

Hi;

I have tried another another way. I ran the chmod on the simple-scan.desktop file in usr/share/applications as I thought this is where the GUI would run from. But it still gives me the following:

Failed to run simple-scan as user root.

The underlying authorisation mechanism (sudo) does not allow you to run this program. Contact the system administrator.

Even though:
in usr/share/applications
-rwxrwxrwx 1 root root 219 2010-12-28 15:51 simple-scan.desktop
and:
in usr/bin/
-rwxrwxrwx 1 root root 121532 2010-10-22 09:00 simple-scan

I don't know where else I can give permissions!!!
Please help.
Jacues

you are still missing the setuid value on simple-scan, there should be a captial "S" in your permissions listing if you have done this:

$ sudo chmod u+s tmp
$ ls -l tmp
-rwSr--r-- 1 root root 23 2011-01-14 12:13 tmp

so you would need to do this for simple-scan:

$ sudo chmod u+s /usr/bin/simple-scan

Hi mycae,

I have done as you suggested and got the following permissions (there was no capital S):
-rwsrwxrwx 1 root scanner 121532 2010-10-22 09:00 /usr/bin/simple-scan

But when I log into my wifes account it still wont run from Applications > Graphics > simple-scan.

BTW I created a scanner group to which we both belong.

I am going to try and set the group and other execute permissions to s and see if this helps.

I'll let you know.

Thanks,

Hi mycae,

The permissions are as follows:
-rwsrwsrwx 1 root scanner 121532 2010-10-22 09:00 /usr/bin/simple-scan

But still cant run it from my wife’s account and GNOME interface.

I have a work around which is a launcher added to the panel which runs the simple-scan application in terminal, but it is a pity that there seems to be no way she can run simple-scan from her account using the Applications > Graphics > simple-scan route.

Please let me know if you have any other suggestions.

Many thanks for your patience,

It should be possible to configure your system so that simple-scan does not need to be run as root. I don't know how to do that, though (maybe your wife has to be a member of the group called "operator"?), so I'll give you the following suggestion instead.

Why does adding a sudoers entry (either to /etc/sudoers via visudo, or as its own file inside /etc/sudoers.d) require that your wife actually run the command "sudo simple-scan"? The gksu program (as it is configured in Ubuntu) acts as a wrapper for sudo, so if you allow your wife's user account to run "simple-scan" with sudo, and then add a launcher that runs the command "gksu visudo", that should enable her to run it.

I'm tempted to ask why you don't just grant your wife administrator privileges. She would be prompted for her password before doing anything that could break the whole system, so even if she is a novice, it seems unlikely that making her an administrator would cause harm. You'd merely have to explain the distinction between running as a regular user and running as root, and how running things as root can be dangerous.

Speaking of the dangers of running things as root: simple-scan (like the vast majority of all applications) is not designed to be run as root by a non-trusted user. If your wife really is a non-trusted user (or any non-trusted person has the ability to use her user account), and you enable her user account to run simple-scan as root, then in doing so you create a backdoor in your system whereby she (or anyone with access to her user account) can perform any action as root. For example, she could (1) create a file in her own home directory containing a sudoers entry that, if added to sudo's configuration, would grant her the power to run any command as root, (2) run simple-scan and go to Document > Email, (3) quit the Evolution Setup Assistant when it comes up, leaving only the web browser, (4) go to her home directory in the web browser, (5) right click the link to the file she created in step 1, and save it as /etc/sudoers.d/foo, where foo is any filename ending with a character that is not . or ~.

If you successfully made the simple-scan executable run setuid root (rather than merely granting your wife's user account the ability to run it as root), then *any* user on your system could become root using the above exploit (or numerous others).

It is for these reasons that simple-scan will refuse to do anything interesting (e.g. create a window, scan documents) if you make it setuid root. The command "sudo chmod +s /usr/bin/simple-scan" will make it setuid root. But then when any user runs it, it will spit out a message like this and quit (and, if not run from the command line, it will appear simply to silently fail to launch):

(process:2679): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

Hi,

So in laymen’s terms the GUI program ignores permissions, is that right?

In response to this line in http://www.gtk.org/setuid.html;

"In the opinion of the GTK+ team, the only correct way to write a setuid program with a graphical user interface is to have a setuid backend that communicates with the non-setuid graphical user interface via a mechanism such as a pipe and that considers the input it receives to be untrusted."

How do I create a setuid backend and pipe that communictaes with the non-setuid GUI?

This all seems a bit over my head but I'll keep at it.

Cheers,

Jacques

First, before we get talking about the way permissions and security works on a Unix-like system, I want to point out that there are simple suggestions that have been mentioned, which you might not have tried so far, and which might solve your problem:

(1) Did you try adding your wife to the "operator" group? It might not work, but if it doesn't, you can always remove her from that group.

(2) Did you try going ahead and adding a sudoers entry for her (either in /etc/sudoers via visudo, or as its own file in /etc/sudoers.d pursuant to the instructions in /etc/sudoers.d/README), to allow her to run the command "simple-scan" with sudo (which, as I explained, should also allow her to run it with gksu), and creating a launcher in her user profile to run the command "gksu simple-scan"? (I apologize for the typo in my previous post, which incorrectly suggested that the launcher should run the command "gksu visudo".)

(3) Did you strongly consider just making your wife an administrator? This is quick and easy and, given that you are able to use the scanner, it should enable her to do so as well. That's assuming, of course, that when you run simple-scan yourself, you run it as root. If you don't have to run it as root yourself, then please mention that, as it would likely lead the way to quick resolution of this problem (we'd just have to figure out what ability your account has that enables it to run simple-scan, and then you could give that ability to your wife's account).

With all that said....

"So in laymen’s terms the GUI program ignores permissions, is that right?"

No.

In a Unix-style filesystem, a file has a user owner and a group owner. That means that, with respect to using any file, there are three meaningful kinds of users on the system (though some might be empty):

(1) The user who owns the file.
(2) Other users who are members of the group that owns the file.
(3) Other users, besides the above.

There are also three operations that can be performed with a file:

(1) Reading the file.
(2) Writing to (changing) the file, which includes deleting, moving, and renaming it. (Renaming is really just moving a file to a different name, but people tend to think of it as a separate operation.)
(3) Executing the file; that is, running it as a program. This is meaningful for any file, though only files of several special forms can actually be executed successfully. Executing a directory (i.e. a folder) is not meaningful, but directories have another operation that is meaningful only for them: entering (or traversing) into the directory. To have "execute permission" on a directory means that you can enter the directory.

When you view a file's Unix-style permissions, you see which of these three operations (if any) can be performed by each of those three kinds of users. For example, on my system, the command "ls -l /usr/bin/simple-scan" gives this output:

-rwxr-xr-x 1 root root 140064 2010-10-22 03:59 /usr/bin/simple-scan

The part that says "root root", read from left to right, means that root is the owner, and that the group called root (which contains just the user called root, by default, and should almost always stay that way) is the group owner.

The part that says "-rwxr-xr-x" is the permissions. It's pretty compact. But it tells me nine things. (Actually it tells me more, but these are the main nine things it tells me.) The user called root (1) can read, (2) can write, and (3) can execute the file; any other users in the group called root (4) can read, (5) cannot write, and (6) can execute the file; and any other users on the system besides root and users in the group called root (7) can read, (8) cannot write, and (9) can execute the file.

Your /usr/bin/simple-scan would have started out with those same permissions. All users on your system were able to execute it, i.e., all users were able to run simple-scan. Including your wife.

(By the way, one mistake to avoid is to think that you can prevent someone from running a program just by taking away their execute permission. This is generally false. If they still have read permission, they can make their own copy of the file, and since they own their own copy, they can change its permissions, giving themselves execute permission. If they don't have read permission either, then if they can find the same--or a similar--program on another system, they can bring that over to the system, and run that copy instead. Correctly set execute permissions is a very important part of having a secure system, but execute permissions do not generally enable you to control the programmatic functionality people have access to. Instead, execute permissions are important--besides in the case of directories--for other reasons. For example, by not marking a file as executable until you know it's trusted, you can avoid running malware.)

How can I say that your wife has always been able to run simple-scan? That must be a mistake, right? No. From what you've said, it sounds like she *has* always been able to run it. She just can't *use* it to operate the scanner.

Why is it that root can use the program to operate the scanner, but your wife cannot? The reason is that a program's capabilities are determined by *who* is running the program. Two different users (e.g. your wife, and root) can run the *same* file, but their different identities mean that the file has different limitations on what it can do when it is running.

To put it another way: Suppose you had a user who you *didn't* want to be able to access the scanner. As I alluded to in the long parenthetical paragraph above, even if they couldn't *execute* /usr/bin/simple-scan, they could still make their own copy of that file, or bring a copy over from their own Ubuntu system. Any user can create (or obtain) their own executable file to perform *any* action. What stops them from actually using it to perform that action is their inability to run it as a user who has that ability.

A small minority of programs do actually act as gatekeepers to the functionality they contain. These programs are sometimes setuid and/or setgid. When one user (say, root) owns an executable file that is setuid, and another user (say, your wife) executes the file, the file executes as root, instead of as your wife. That is, your wife has the ability to **become root** by executing that file.

Once I said "become root" you probably guessed one program that is setuid: sudo. That is one of a handful of programs that is setuid on a modern Unix-like system. Every line of code in sudo, every design idea that informs its construction, had to be meticulously vetted to to minimize the chance that it would introduce a backdoor into sudo that would allow unauthorized users to perform actions as root that they're not intended to be able to perform. Writing a program that is intended to be owned by root and setuid requires a very different design than writing programs in general. As a result, the vast majority of all programs should never be made setuid root. This probably includes all graphical programs, as the GTK+ documentation indicates, since graphical programs are inherently more complicated in various ways. But it also includes almost all non-graphical programs.

When a program is setuid, its execute permissions really do control who can perform certain actions on the system. Unlike with non-setuid programs, a setuid program allows users to *become* the user who owns the setuid program, by running it. If a user makes a copy of a setuid program, they can run the copy...but the copy would be owned by them instead of the original owner, so making a copy (or importing a setuid executable from another system) are *not* effective ways of circumventing execute permissions on setuid programs.

A setgid program is like a setuid program, except that it runs with the group identity of its group owner, rather than the user identity of its owner. (A program that is neither setuid nor setgid runs with the user and group identities of the user who runs it; that's the ordinary behavior, appropriate for nearly all programs.) Setuid and setgid do something different when applied to directories. You can read about that, and about setuid/setgid in general, by checking out http://en.wikipedia.org/wiki/Setuid and the references and external links therein. You can read about Unix-style file permissions in greater detail at https://help.ubuntu.com/community/FilePermissions and by searching the web for "unix file permissions" and "unix permissions". You may have noticed that, when I explained the meaning of the ten-character long string -rwxr-xr-x, I only talked about the last nine characters. See http://en.wikipedia.org/wiki/Filesystem_permissions#Symbolic_notation for an explanation of the first character. Finally, I should mention that while most programs should never be made setuid/setgid, shell scripts should never *ever* be made setuid/setgid (reading the above sources and their citations will explain this).

"How do I create a setuid backend and pipe that communictaes with the non-setuid GUI?"

That is a design guideline for programmers, and not for users or system administrators. To do that, if you aren't already a proficient computer programmer, you would have to learn programming and gain experience doing it. You would also have to extensively study Unix security. This is certainly not a reasonable avenue for fixing your scanner issue. As an example of the relationship between a non-setuid GUI frontend and a setuid non-GUI backend, consider the relationship between gksu (or gksudo) and sudo.

If you're interested in learning more about your system in a way that is directly useful to your current problem, I would suggest investigating how to allow not-root users to access your scanner (that is, how to allow your wife to use the scanner without her having to elevate her privileges to root; that is, how to enable her to run simple-scan as herself and not root, and be able to use the scanner). I really think there has got to be a way. Scanners are accessible by non-root users on some other Unix-like systems, including some Linux-based systems. Hopefully someone who knows the answer to that question will post here, providing a perfect (or near-perfect) solution to your problem. (My first suggestion at the beginning of this post is a guess as to how to accomplish that, but I am not at all confident that it will work and I don't currently have a scanner setup that I can use to test it. You could test it easily, though.) Until then, you have the second and third suggestions I reiterated at the beginning of this post.

If you follow the second suggestion (adding a /etc/sudoers or /etc/sudoers.d entry for your wife to run the command "simple-scan") and it doesn't work, please post again, because that *really* should work.

Hi,

I have followed steps 1 to 3 above and the only one that works is step 3.
I have given my wife admin privileges and that solved the problem.
Upon adding her to the sudoers file the program does not provide feedback but just doesn't run.
I think I will stick to the simplest option. Thanks for all your advice. It was really helpful and complemented everything I read on the web.

Thanks again,

jacques

I'm glad I was able to help, though sorry I was unable to help more.

If in the future you want to try to get it working with sudoers entry and want assistance, please feel free to reopen this Question (or to start a new one).

If your /usr/bin/simple-scan is still setuid and setgid root, then you should really undo that. It will still run as root, but it's a bad thing to have programs floating around on your system that are owned by root and setuid/setgid. To unsetuid and unsetgid it, you can run the command:

sudo chmod -s /usr/bin/simple-scan

Also, if you modified /etc/sudoers (via visudo) or created an entry (a file) in /etc/sudoers.d in an attempt to give your wife the specific ability to run simple-scan as root via sudo, and the modification was unsuccessful, it's probably a good idea to undo it.

Thanks Eliah,
I have learnt a lot in these past few weeks since installing Ubuntu and have to say it is thanks to people like you who are willing to give advice and guidance in your own time.
I will be able to give permissions and understand how Linux file and folder security operates. I have undone all the changes to the files I have worked on, and it all should be back to being a secure system.
Best wishes,
jacques