LXer: The Ultimate Sudo FAQ — To Sudo Or Not To Sudo?
 

Published at LXer:

Sudo is a simple program which allows the administrator to give regular users extra permissions to execute the commands they would normally not be allowed to use. In order to use sudo you need to configure it properly. This FAQ is supposed to help you with this task.

Read More...

The Polish 'sudo' tutorial does not address "To Sudo Or Not To Sudo". It shows how to use 'sudo' but doesn't address when 'sudo' is needed.

How does one know when they need 'root' privilege? I've 'sudo'ed what to me was system-type stuff only to be told by Linux gurus, "Don't run this as 'root'". At other times, some system-type task can only be accomplished as 'root'. How is one to know? (Hint: Getting an error message is not a sufficient clue.)

Another thing: (I write this as a Linux novice, but this is my notion...) When you 'run as Administrator' in MS-Windows, you merely borrow the Administrator's credentials, not the Administrator's identity. Thus, you end up as owner of anything that's created. But in Linux, when you 'sudo' or 'su', you apparently BECOME root, so 'root' winds up being the owner of things that are created. That's very different. Linux appears to work around the problem by setting rights to: '-rwxrwxrwx'. I don't much like that.

I'm probably wrong in half of what I write about above. If so, I'd sure like to be straightened out.

Hi,

By considering what files need to read or written to, and what their permissions are (and by reading the man page of the command).

Not sure if I would consider this a "problem" to be worked around. chown is your friend.

Evo2.

Hi evo2. You have over 3400 posts, so I'm going to consider you to be an authority. Now, up front I want to acknowledge your authority and I also want to confess that, 1, I'm a Linux novice, and 2, I've gotten thrashed in some Linux forums recently and have been accused of being a troll. I'm sure that in my detractor's eyes I appeared to be a troll. But "Don't feed the troll" can be an effective way to evade questions, can't it? I ask hard questions because I'm a computer architect.So the permissions of existing files, presumably '.config' files mostly - right? - determines whether I need 'root' privilege? So, for example, if an installer needs to alter a '.config' file and that file is owned by 'root' and 'others' don't have 'w' privilege, then I have to 'sudo' in order to run the installer. Do I have that right? Is that what you meant?

I recently installed 'Evolution' and 'lxmed'. I installed 'Evolution' via 'mintInstall' (which required me to supply the 'root' password - I guess invocation of 'gksudo' is built-in), but I had to install 'lxmed' manually. In the 2nd case, how am I to know whether to 'sudo' or not? Of concern is not that I might not 'sudo' when I should because I assume that, in that case, the install will fail. My concern is that I'll use 'root' to install something that shouldn't be installed as 'root', as when the Linux gurus told me I'd screwed up - BTW, I don't know why that was a screw-up... well, maybe I do: 'root' will wind up as 'owner'.What effect will changing the 'owner' have when 'others' have 'rwx' rights? It seems to me to be no change at all, and a security fault, but I don't know for sure because I'm a novice.

You also recommended consulting 'man' pages. In the case of lxmed, there's no 'man' page and no 'info' page. What do you do?

(I have a lot more questions, but this will do for now.)

Thanks - Mark (who's just trying to figure it out in advance so he doesn't wind up repeatedly reinstalling during his learning period).

Exactly.

It comes down to: If you make a system-wide install you need root privileges, if you install to your /home-directory (install only for your user) you don't. If you are unsure just try it without root privileges, the installation may fail, but since you don't have the rights to alter system files your system won't be damaged.

Others shouldn't have rwx rights in the first place. There is a good reason why system files usually only are writable for root. If your user really needs access to them changing the owner or group is the way to go, changing permissions for others to rwx is punching big security holes into your system.

Have a look in your /usr/doc or /usr/share/doc (depending on the distro) directory for documentation for lxmed, if you don't find such the website of that software is the place to search for information. As is when you want to install software that is not part of the repository anyways. In the case of lxmed the installation procedure is documented and tells you that you need root privileges for the install.

Since I have already stated my own thoughts about when and when not to use sudo I hope others won't mind if I just quote myself. ;)

P.S. As to when to use either, I would suggest that if you can achieve a task without privileged escalation then that is probably the way to do it. For this reason I tend to build packages with fakeroot rather than switching to actual root or using sudo.

I disagree here. I use both, su and sudo on my personal machines. Usually I use su for system admin tasks, but I also have configured sudo to allow me to execute a few programs without typing in a password, just because these are commands I use often (mount for loop-mounting ISO files, for example) or because I just don't want to type in my password to reboot the machine (no fancy DE here and I think that I am faster opening the terminal and typing in sudo reboot as most people are with using the mouse in their DE for the same task).

Hi,

Careful, it could be 3400 posts of utter rubbish ;-)

Pretty much.

Ok, this is a litle more subtle. Any sort of compilation should *not* be done as root. The actual installation (which in this case just means copying files to different locations), would typically need to be done as root: again for the simple reason that if you want to put a file in specific directory you need permission to write to that directory. If you are doing system wide installs (ie not just intalling to your home directory), then the install location should generally be in /opt or /usr/local. If I want to install something to opt I'll usually make a directory there as root, (since opt will generally only be writiable by root). Eg if I want to install Foo version 3.14 I'd do something like

then proceed as user evo2.

When installing in /usr/local I can usually do everything as evo2, since I've made /usr/local writable by members of the group "staff" and I've put evo2 in that group. I like this method becuase it ensures that what I install 3rd party software (that has not undergone the same sort of auditing as the code from the official Debian repos), I am not running any of the install scripts as root. Any damage that these scripts is reduced to the permissions of the user evo2. Eg doing something nasty/overwriting files in places like /bin/, /usr/bin/, /usr/lib and so on.

This is a different case: you are running some sort of installer. There should be some sort of documentation that comes with it. Eg a README or INSTALL file. Better still you can look at the install scripts/Makefiles etc themselves.

No problem. Hope you find LQ a useful resource.

Evo2.

You've answered my questions, Tobi.

Not to quibbleI 'hear' you, but I don't think I will know a '/' install from a '~' install. Is it based on 'a feeling'?That's it! That's easy. Thanks for giving me a clear cut method.I usually find that stuff quite unreadable. I'm sure I'll get better at reading 'between the lines', but right now when I read most of the stuff developers write about Linux applications I'm lost in jargon and ambiguity. Almost all of the 'man' pages I've read under-specify the argument list, especially when command line switches can interact.

Unless you get back here and tell me I misunderstood, I'll stick with your advice to first try installing as an ordinary user, and then using 'sudo' only if that doesn't work.

Thanks - I'm off to see the wizard. Ciao - Mark.

Dear ruario,

You go on to compare 'su' v. 'sudo' on the basis of efficiency. However, I've done some experiments and I've found some significant differences in the environment created for 'su' versus the environment created for 'sudo'. The subject is a little OT for the OP... but there it is.

PS: And one distinction that should be made that Linux gurus don't usually address is the difference between 'su' and/or 'sudo' in Linux (or Unix) versus 'run as Administrator' in MS-Windows, to wit: When an ordinary Linux user elevates via 'su' or 'sudo', the $USER becomes 'root', whereas when an ordinary Windows user elevates, the $USER remains 'mark' in my case. A further complication: 'su' retains 'mark' as $USERNAME while 'sudo' changes $USERNAME to 'root'. In other words, In Windows, a user borrows the Administrator credentials while fully retaining his/her identity, whereas in Linux, a user's identity is either partly ('su') or fully ('sudo') buried. This difference in ownership has to have an effect.

You mean $USER not $USERNAME. In any case you are wrong with regards to su, your username will always be root if you switch to root since su actually means 'switch user', with the default being root if you do not specify another user.

Try running whoami, under su and sudo, e.g.

The complication is usually with regards to sudo. Consider the following:

The reason that 'sudo echo $USER' shows my username as ruario, rather that root is because the shell must expand the variable with its actual value before the sudo command can be run (and at that point I am still ruario). However applications run under sudo are still running as the root, as the whoami example above demonstrates.

As it happens to is possible to see the same problem with su if you were to do the following:

It is failing for the same reason as with sudo. If however I protect the expansion of $USER from my shell (bash in this case) with single quotes, it will work as expected:

Indeed the fact that variables can be inherited from the current user can indeed cause issues and is something you need to be aware of. If you want to ensure you really are root and only have the variables that root would normally have set, it is safest to issue 'su -'. This provides an environment similar to that of logging into root directly.

Yeah it is a fair point and if you read the sentence previous to the one you quoted I do actually aknowledge this:

(bolding added)

I must admit that in hindsight my comment about sudo being pointless for single users is an exaggeration and a bit ranty, plus it somewhat contradicts the previous statement. I think I wrote it this way as it was in a Slackware installation thread and too many times I have read complaints from users who are new to Slack (typically from a distro like Ubuntu) failing to understand that sudo isn't needed for everything (as it happens the user from that particular thread does not say or imply this but others have).

Anyway, next time I quote myself I'll leave that sentence out. ;)

Mostly experience, with a bit of logic. Software that comes already packaged for your system (.deb, .rpm or .txz files, dependent on your distribution) will always need root privileges. When it comes down to installers that is different, software that has to be installed systemwide because it adds features to the system, like video-drivers or software like Virtualbox, will also need root privileges. Other installers may give you the choice where to install the software, for most games that come as installer this is the case. With software that has to be compiled from source it depends on the type of software, some have to be installed systemwide, some can run from your ~-directory.

Of course sometimes one needs just a little bit more knowledge to install a specific software, but usually it comes down to the triplet of Once you have grokked that it is quite easy to understand installation instructions.

That is the way to go. Of course you are also free to ask questions here in case you are unsure how something works.

Sorry, Ruarí. I seem to have missed your post.No, I mean $USERNAME. Look...
The above is heavily pruned. My system seems to run differently from yours. What do you make of it?
You've given me quite a bit to contemplate. Thanks!