LXer: The Ultimate Sudo FAQ To Sudo Or Not To Sudo?
Syndicated Linux NewsThis forum is for the discussion of Syndicated Linux News stories.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.)
By considering what files need to read or written to, and what their permissions are (and by reading the man page of the command).
Quote:
Linux appears to work around the problem by setting rights to: '-rwxrwxrwx'. I don't much like that.
Not sure if I would consider this a "problem" to be worked around. chown is your friend.
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.
Quote:
Originally Posted by evo2
Quote:
Originally Posted by MarkFilipak
How does one know when they need 'root' privilege?
By considering what files need to read or written to, and what their permissions are (and by reading the man page of the command).
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'.
Quote:
Originally Posted by evo2
Quote:
Originally Posted by MarkFilipak
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.
Not sure if I would consider this a "problem" to be worked around. chown is your friend.
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).
Last edited by MarkFilipak; 04-11-2013 at 04:04 AM.
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?
Exactly.
Quote:
In the 2nd case, how am I to know whether to 'sudo' or not?
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.
Quote:
What effect will changing the 'owner' have when 'others' have 'rwx' rights?
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.
Quote:
You also recommended consulting 'man' pages. In the case of lxmed, there's no 'man' page and no 'info' page. What do you do?
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.
Quote:
Originally Posted by ruario
The thing about sudo is that it works best when you have multiple admins on the same machine or want to grant access to individual commands to specific users. However for a personal machine it is pretty much pointless IMHO
Quote:
Originally Posted by ruario
Consider if I wanted to run the fake command 'example' once as a root user. Here is what I would actually have to type (where $password is my actual password).
Using su:
su[Enter]$password[Enter]example[Enter][Ctrl]+d
(Note: That is '[Ctrl]' and 'd' together to exit the root session, you obviously aren't typing the '+' character)
Using sudo:
sudo[space]example[Enter]$password[Enter]
Ignoring the characters needed that are the same in both cases (i.e. 'example' followed by [Enter] and your password followed by [Enter]), you have to type 5 key presses to execute a single command as root via 'su' (s u [Enter] [Ctrl] d) and 5 key presses to execute a single command as root via 'sudo' (s u d o [space]). Or to put it another way, you save nothing using sudo.
If however you wanted to type two or more commands as root, you immediately start saving on the key presses by using 'su' instead of 'sudo'. Yes the second 'sudo' command does not require a password but as long as you have not closed your root session yet (i.e. no Ctrl+d) you don't have to type your password again with 'su' either and you save having to write 'sudo' for every single line.
There is also the point that outside of distros where 'sudo' is preconfigured (e.g. Ubuntu and derivatives) you save time configuring '/etc/sudoers' and setting up various admin variables for your regular user.
Indeed the other nice thing with using 'su' is that you can just open a root terminal for all your admin needs and you decide if and when you should close it, rather than relying on preconfigured time-out periods with 'sudo'.
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.
However for a personal machine it is pretty much pointless IMHO
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 evo2. You have over 3400 posts, so I'm going to consider you to be an authority.
Careful, it could be 3400 posts of utter rubbish ;-)
Quote:
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?
Pretty much.
Quote:
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.
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
Code:
mkdir /opt/Foo-3.14
chown evo2:evo2 /opt/Foo-3.14
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.
Code:
You also recommended consulting 'man' pages. In the case of lxmed, there's no 'man' page and no 'info' page. What do you do?
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.
Quote:
(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).
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.
I 'hear' you, but I don't think I will know a '/' install from a '~' install. Is it based on 'a feeling'?
Quote:
Originally Posted by TobiSGD
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.
That's it! That's easy. Thanks for giving me a clear cut method.
Quote:
Originally Posted by TobiSGD
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.
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.
Consider if I wanted to run the fake command 'example' once as a root user. Here is what I would actually have to type (where $password is my actual password).
Using su:
su[Enter]$password[Enter]example[Enter][Ctrl]+d
(Note: That is '[Ctrl]' and 'd' together to exit the root session, you obviously aren't typing the '+' character)
Using sudo:
sudo[space]example[Enter]$password[Enter]
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.
Last edited by MarkFilipak; 04-12-2013 at 12:44 AM.
Reason: Added PS.
A further complication: 'su' retains 'mark' as $USERNAME while 'sudo' changes $USERNAME to 'root'.
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.
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:
Code:
$ su -c "echo $USER"
Password:
ruario
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:
Code:
$ su -c 'echo $USER'
Password:
root
Quote:
Originally Posted by MarkFilipak
This difference in ownership has to have an effect.
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.
Last edited by ruario; 04-12-2013 at 03:05 AM.
Reason: Added clarifications and final paragraph
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
Yeah it is a fair point and if you read the sentence previous to the one you quoted I do actually aknowledge this:
Quote:
Originally Posted by ruario
The thing about sudo is that it works best when you have multiple admins on the same machine or want to grant access to individual commands to specific users.
(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.
Not to quibbleI 'hear' you, but I don't think I will know a '/' install from a '~' install.
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.
Quote:
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.
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
Code:
./configure
make
make install
Once you have grokked that it is quite easy to understand installation instructions.
Quote:
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.
That is the way to go. Of course you are also free to ask questions here in case you are unsure how something works.
A further complication: 'su' retains 'mark' as $USERNAME while 'sudo' changes $USERNAME to 'root'.
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.
No, I mean $USERNAME. Look...
Code:
mark@Iris ~ $ su mark@Iris ~ $ sudo env
Password: [sudo] password for mark:
Iris mark # env
HOME=/root HOME=/home/mark
LOGNAME=root LOGNAME=root
USER=root USER=root
USERNAME=mark USERNAME=root
The above is heavily pruned. My system seems to run differently from yours. What do you make of it?
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:
Code:
$ su -c "echo $USER"
Password:
ruario
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:
Code:
$ su -c 'echo $USER'
Password:
root
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.
You've given me quite a bit to contemplate. Thanks!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.