Beta

# Got Root - Should You Use It?

#### Cliff posted more than 7 years ago | from vegthura

245

vegthura asks: "I have several coworkers that insist that logging into servers is an acceptable practice. They claim it's just easier than using sudo and it's just as safe - you know you're root so what else do you need? And why bother logging in as you if you're just going to use sudo to run commands with root privileges anyway? Everything I've ever read has been the exact opposite philosophy. There is very little you need to be root to do, if anything in practice, and using sudo lets you only use the power of root for when you really need it. So, die hard unix geeks, you've got root... do you use it or stick to sudo?"

cancel ×

### No Comment Title Entered

#### Anonymous Coward 1 minute ago

No Comment Entered

### Simple solution (1)

This comment was hidden based on your threshold setting.

### Re:Simple solution (2)

This comment was hidden based on your threshold setting.

#### dshaw858 | more than 7 years ago

I do this on all of my servers. And even more, there's this great command if you really need a root shell:
sudo su

Amazing, isn't it? You can login as you and still spawn a root shell if you really need to.

It's easier that way.

- dshaw

### Sudo wins for me (4, Informative)

This comment was hidden based on your threshold setting.

#### Smitedogg | more than 7 years ago

Using sudo, you can allow 'some' root commands to other users/admins without opening up the vault, and you can do a lot of smart things like keep root unable to be logged into, or have a true strong password that you can lock in a safe somewhere, all without losing functionality.

### Re:Sudo wins for me (1)

This comment was hidden based on your threshold setting.

#### ubersonic | more than 7 years ago

Might as well just link to the manpage ;)
SUDO(8)

### Root (1, Insightful)

This comment was hidden based on your threshold setting.

#### nagora | more than 7 years ago

The only reason to log into a server is to do admin work, which will require root. If there's something you are doing on the server that doesn't need root then you probably shouldn't be using the server for that.

I generally only have one user on servers and that's root. Everyone else can access it via nfs/samba/ftp/whatever, but only root gets login.

TWW

### Wrong (3, Informative)

This comment was hidden based on your threshold setting.

#### metamatic | more than 7 years ago

Good practice is to avoid running server tasks as root unless absolutely necessary, and there are all kinds of server admin tasks you might need to do, that don't need to involve becoming root. Database administration, for example.

### Re:Wrong (1, Informative)

This comment was hidden based on your threshold setting.

#### Anonymous Coward | more than 7 years ago

Not to mention, by having individuals log in, and use sudo, you can track who did what, when. If everyone logs in as root, you have no idea who it really was. If they log in as themselves, and screw up, there's at least a good chance that it was them that did it.

### Re:Wrong (0)

This comment was hidden based on your threshold setting.

#### Anonymous Coward | more than 7 years ago

Why are other people logging into my server?!? Have I been hacked?? It's my server, damnit, I'm the only one who gets to touch it!!! Tell those other assholes to stay logged out!

Sincerly,
Root

### Re:Wrong (1)

This comment was hidden based on your threshold setting.

#### foQ | more than 7 years ago

Mod parent up, please. Logging in as yourself provides both accountability and another layer of defense against hacking.

### More than just root (5, Informative)

This comment was hidden based on your threshold setting.

#### Sentry21 | more than 7 years ago

Using sudo provides a host of benefits besides giving you root. Sudo allows you to grant access to specific users for specific commands, and then revoke those commands later. Compare this with giving the root password to everyone, which requires the password to be changed whenever someone leaves the company (or someone's root privs are revoked).

I can grant access via sudo to users for specific commands, without giving them complete administrative access to the entire system.

When I'm using 'sudo' to do things, my environment stays the same. This means that my $PATH variable stays the same, and so does my prompt. It means that any time I say ~ it refers to /home/myusername and not /root, meaning I can get to it later. When I'm not using sudo and I do 'cd /var/www/certs/domainname/' and it doesn't give me an error, I know that the permissions are wrong on that directory (more of a reminder than anything). I've gotten so used to this on most systems that the series of commands I use to access the IMAP virtualhost directory is essentially 'cd /var/spool/postfix/virtual; sudo bash; cd /var/spool/postfix/virtual', which slows me down surprisingly not much. It doesn't take much to hit the up arrow, Ctrl-A, type 'sudo ' and then hit enter if you find you need to. I can set in ~/.bash_profile that I want rm to use -i by default (alias rm='rm -i') for safety, which carries over into my 'sudo' environment; doing this for root by default can cause e.g. cronjobs to hang, waiting for input that will never come. The benefits of sudo are not limited to 'gaining root' - they are multitudinous, and apparently your coworkers have never considered versatility to be a benefit; nor, for that matter, have they done likewise for security. Perhaps they should be educated. ### Re:More than just root (1) This comment was hidden based on your threshold setting. #### akgunkel | more than 7 years ago My hat is off to you sir. This may be the best, most intelligent answer to an "Ask Slashdot" question that I've ever seen. Bravo. ### Re:More than just root (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago > It doesn't take much to hit the up arrow, > Ctrl-A, type 'sudo ' and then hit enter if you find you need to. That's good, but in bash, even easier: sudo !! Will do the same. ### Re:More than just root (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Bravo on a great answer. One nit: > I can set in ~/.bash_profile that I want rm to use -i by default [...]; doing this for root by default can cause e.g. cronjobs to hang, waiting for input that will never come. bashrc is only read by interactive shells, so this is not a problem ### Re:More than just root (2, Interesting) This comment was hidden based on your threshold setting. #### Henry V .009 | more than 7 years ago There are benefits to using sudo, and depending on the situation some of those may become very important. But one con I'd like to point out is the dependence on the sudoers file. You can mangle a system (requiring a reboot to single-user) with one wrong entry. And if you are constantly editing it to give users fine-grained privileges, that risk is important to weigh against the benefits. And if (as with my current job) you work someplace with: 1. Low employee turnover. 2. Lots of servers. 3. Few people with root access. 4. LDAP authentication for passwords to make changing the root password on all servers easy. Then maintaining seperate sudoers files on every server is far more pain than it's worth. ### Re:More than just root (1) This comment was hidden based on your threshold setting. #### texroot | more than 7 years ago Good point about the convenience of LDAP and centralized authentication, though I'm not sure how I'd like having root login be dependent on LDAP. As for the sudoers file being mangled, using visudo should check for correct syntax and not let you save the changes if they would render it nonfunctional. ### Re:More than just root (1) This comment was hidden based on your threshold setting. #### Henry V .009 | more than 7 years ago There is nonfunctional and there is nonfunctional. Commenting out the wheel line can disable all root access (depending on your setup) and visudo won't help you with that. ### Re:More than just root (1) This comment was hidden based on your threshold setting. #### tek.net-ium | more than 7 years ago Sudo allows you to grant access to specific users for specific commands, and then revoke those commands later. Compare this with giving the root password to everyone, which requires the password to be changed whenever someone leaves the company (or someone's root privs are revoked). I can grant access via sudo to users for specific commands, without giving them complete administrative access to the entire system. ssh keys, or kerberos can give the same advantages. Allowing root password ssh logins is just stupid. When I'm using 'sudo' to do things, my environment stays the same. This means that my$PATH variable stays the same, and so does my prompt. It means that any time I say ~ it refers to /home/myusername and not /root, meaning I can get to it later.

I can set in ~/.bash_profile that I want rm to use -i by default (alias rm='rm -i') for safety, which carries over into my 'sudo' environment; doing this for root by default can cause e.g. cronjobs to hang, waiting for input that will never come.
Yeah, except that frequently servers have some other environment than your typical desktop (different OS or whatever), so you might need to set unique environments for each. Also, I usually want my servers functioning effectively as islands: I don't want them to have access to home directories, because my servers are typically publicly facing and are more likely to be comprimised.
The benefits of sudo are not limited to 'gaining root' - they are multitudinous, and apparently your coworkers have never considered versatility to be a benefit; nor, for that matter, have they done likewise for security. Perhaps they should be educated.
I find the versitility of being able to change an arbitrary number of servers at once far more beneficial than having to manually login to each and modify the same config file or whatever by hand. Sudo's also been affected by a number of security problems recently, which tend to allow your carefully constructed ACL's to be bypassed. See http://www.courtesan.com/sudo/security.html .

### Re:More than just root (1)

This comment was hidden based on your threshold setting.

#### Sancho | more than 7 years ago

ssh keys, or kerberos can give the same advantages. Allowing root password ssh logins is just stupid.

How do ssh keys allow you to restrict the commands that can be used?

As for the sudo advisories.... well 8 in five years isn't all that bad, and most of them are somewhat common sense (let someone execute a scripting language and yeah, it's probably going to be somewhat insecure).

### Re:More than just root (3, Insightful)

This comment was hidden based on your threshold setting.

#### Deorus | more than 7 years ago

> Compare this with giving the root password to everyone, which requires the password to be changed whenever someone leaves the company (or someone's root privs are revoked).

Create multiple UID 0 accounts with different passwords.

As for the rest of your post, I'd rather not trust the security of a server to sudo, firstly because it had security issues in the past, and secondly because it's not a trivial task to decide which commands a user can and can not have access to.

### Re:More than just root (2, Insightful)

This comment was hidden based on your threshold setting.

#### teknomage1 | more than 7 years ago

Isn't the sysadmin's job to decide which commands a user can and can not have access to?

### Re:More than just root (2, Informative)

This comment was hidden based on your threshold setting.

#### JollyFinn | more than 7 years ago

As for the rest of your post, I'd rather not trust the security of a server to sudo, firstly because it had security issues in the past, and secondly because it's not a trivial task to decide which commands a user can and can not have access to.

rm -rf /

bash -c select X in ls /* -A; do{ select Y in ls X; do 777 > Y ;cd ..};#My first shell script probably buggy but gives idea what it should do

emacs -f (delete (recursivegeneratepathtoallfiles "/"))

vi -c #Too tired to do the damanging function but still it could be done.

rm, bash, emacs, vi, are out of limits expecially last 3 since those 3 can generate what ever sequenceas you could consider. There are plenty of other programs that should be out of limits for normal users to get sudo.

### Re:More than just root (2, Informative)

This comment was hidden based on your threshold setting.

#### c0nman | more than 7 years ago

sudo bash ???

Do people actually do that? If you want a root shell it's sudo -s. But that is NOT the purpose of sudo. You want accountability on your server(s).

And as pointed out by another already, sudo !! or sudo !-2, sudo !-3, sudo !command... Understanding your environment should be one of the first things you learn.

user/server:/path$vi /var/named/chroot/var/zones/master/d/domain.tld "/var/named/chroot/var/zones/master/d/domain.tld" [New File] user/server:/path$ ls -l /var/named/chroot/var/zones/master/d/domain.tld
ls: /var/named/chroot/var/zones/master/d/domain.tld: Permission denied
user/server:/path$sudo !! sudo ls -l /var/named/chroot/var/zones/master/d/domain.tld -rw-r----- 1 named wheel 7185 Aug 6 2005 /var/named/chroot/var/zones/master/d/domain.tld user/server:/path$ ^.^2.
sudo ls -l /var/named/chroot/var/zones/master/d/domain2.tld
-rw-r----- 1 named wheel 1121 Aug 6 2005 /var/named/chroot/var/zones/master/d/domain2.tld
user/server:/path$sudo -s root/server:/path# id -p login user uid root groups wheel kmem sys tty operator staff guest root/server:/path# ^D exit user/server:/path$ tail -n3 /var/log/secure
tail: /var/log/secure: Permission denied

### Re:Use sudo rarely? (1)

This comment was hidden based on your threshold setting.

#### BobPaul | more than 7 years ago

On both my Ubuntu box at home and Gentoo servers at work, logging in as a user and then issueing "su" (or "sudo su") causes the environment variables to be the same as if I logged in as root directly, so I'm not sure what you're referring to.

Generally, I use sudo, even if I have a lot of commands to do. I feel it's a better idea as every command I enter is in just one log. Anything I do with "sudo" is in the system log while anything I do with su is in /root/.bash_history, which of course, is more volatile. For logging purposes, especially if there are many administrators who have access to the server, sudo is just more organized, there's just one place to turn if things aren't working, plus you can identify the individual.

Get a programmable keyboard and program a key to macro "sudo " for you or even "[Up][Home]sudo [Enter]" if you have trouble with the extra 5 characters you occasionally need. Or us an alias like s=sudo if your cheap. I recommend the keyboard. (You can even put your password on CTRL+ALT+SHIFT+F12 to make things easier)

### It depends... (5, Interesting)

This comment was hidden based on your threshold setting.

#### D'Arque Bishop | more than 7 years ago

For me, it all depends on whether or not the machine is one I directly own or control.

If it is one I personally own or am more or less directly responsible for above anyone else, then I use root if needed.

If it's one that I don't personally own or I'm reporting to someone else who's ultimately responsible for the machine, I don't ask for the root password and request sudo access instead. That way, there's a log of my actions so I can go back and show exactly what I was and wasn't responsible for doing. Showing accountability is key when you're in a position of trust, IMHO.

Just my $.02... ### Re:It depends... (1) This comment was hidden based on your threshold setting. #### anticypher | more than 7 years ago On machines that are not owned by me, but where I can influence the security policy, sudo is the only mechanism I permit. The only root logins are on the console (since they are all stuck in data centres, phyical access is very limited). Forcing sudo causes more responsible behaviour on everyone's part, and knowing that commands are logged, admins tend to think a little more before blowing the system away. On machines where I've enforced a sudo only policy, reliability goes way, WAY up. On my own machines, I still use sudo, but it tends to be 'sudo bash', and I change the color of the xterm to red-on-black so I know it's root. Not the best practice, but I've made enough expensive mistakes in my past to be overly cautious most of the time. the AC ### the second xterm (1) This comment was hidden based on your threshold setting. #### r00t | more than 7 years ago That's the right way to do things, provided that you always keep a few available non-root xterms on the desktop as well. (open the non-root ones first, so you won't be tempted to waste the root one for just looking around and reading man pages) Uhhh... red-on black though? Color change is a good idea, but that's a bit unreadable. Try pink-on-black or white-on-darkred if you have an LCD. If you have a CRT, swap the foreground and background colors. ### The biggest reason (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago The biggest reason not to use root as your actual login shell is to prevent virus infections from being possible. If you're a "normal" user, you don't have write privledges to the executable files of your applications - that means that a virus can't make changes to it, and can't infect it, unless you are stupid and log in as root all of the time. Remember: Install as root, run as a normal user. It's the whole reason you never hear about _ACTUAL_ UNIX viruses on the loose - just "proof of concept" scare tactics from antivirus companies. The separation of administrative privledges from normal user privledges is one of the things that make UNIX type systems a hostile environment for a virus. ### Nah, viruses don't need root (2, Informative) This comment was hidden based on your threshold setting. #### r00t | more than 7 years ago Think about what a virus does these days, remembering that few machines are truly serving multiple people. • It wants a network connection. Normally, every user has access to that. • It wants your email client config. As root, it would need to do more searching to find this. • Supposing you use SE Linux, it wants your SE Linux privs. Perhaps root has been restricted. • It wants a place to store itself: ~/.something-that-looks-legit • It wants a way to activate itself: GNOME session startup files, .bashrc, .bash_profile, cron job So far, I've only found one moderately-useful thing restricted to root: the SYN-flood DoS attack. That's no big deal. A virus certainly doesn't need to patch the kernel or write to /bin. Those are cool tricks of course, but they don't gain any significant resources and aren't necessary for hiding from normal people. ### Ask slashdot; (5, Funny) This comment was hidden based on your threshold setting. #### jericho4.0 | more than 7 years ago My brother insists it's safe to turn off a computer by pouring beer on the power supply. Everything I've ever read has been the exact opposite philosophy. Who is right? ### Re:Ask slashdot; (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Mod this up ### Re:Ask slashdot; (0) This comment was hidden based on your threshold setting. #### bevo14 | more than 7 years ago Of course it is safe. Just stand back. ### Re:Ask slashdot; (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago I think that the primary question is what type of beer. Budweiser, et al, should not be a big problem as they are no different than water. A good stout might prove too thick for the average PC cooling fan to seize. Using Root Beer might be the best option : ) ### Re:Ask slashdot; (2, Funny) This comment was hidden based on your threshold setting. #### enrgeeman | more than 7 years ago not root beer, sudo beer! ### Re:Ask slashdot; (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago My apologies. I stand corrected. A quick question...is Sudo a Japanese or Chinese brewer? ### Re:Ask slashdot; (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Depends on the quality of the beer ### I'm a loner, Dotty. (1) This comment was hidden based on your threshold setting. #### supersocialist | more than 7 years ago It's not what you do as root... it's what malware running without your knowledge does with root. Obviously. That said, I'm running XP, so in the end it's "not root is safer, but I like to live dangerously." ### sudo... (1) This comment was hidden based on your threshold setting. #### stoney27 | more than 7 years ago I think you should use sudo, besides cutting down on the "oops I typed that command as root" mistakes. It also logs all commands run as root. Well when you run sudo . Even if you don't look at the logs that much. It will give you a record on who fixed what and when. Just incase something does go wong. -S ps hi joe! ### It's all about logging (5, Insightful) This comment was hidden based on your threshold setting. #### forsetti | more than 7 years ago Given rich ACLs, there is really very little that needs to be done as root. However, when root is needed, it is important to remember that there is only one root. On a machine with multiple admins, how do you tell who logged in as root? The sudo log entry tells all: Apr 15 22:05:41 linux-black sudo: matt : TTY=pts/0 ; PWD=/home/matt ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log sudo is valuable if only for the logging. Yes, you can limit what can be done using the sudoers file, but logging who did what is invaluable. ### Re:It's all about logging (1) This comment was hidden based on your threshold setting. #### (H)elix1 | more than 7 years ago And to play devil's advocate, this is exactly the reason to log as root. You sudo and hork something up, they can tell exactly who did it... And to play devil's advocate, this is exactly the reason to log as root. You sudo and hork something up, they can tell exactly who did it... (grin) ### Re:It's all about logging (1) This comment was hidden based on your threshold setting. #### Deorus | more than 7 years ago > On a machine with multiple admins, how do you tell who logged in as root? Disable root logins completely and have everyone su to root whenever they need super-user privileges. PAM allows you to do this. ### Re:It's all about logging (1) This comment was hidden based on your threshold setting. #### dvanduzer | more than 7 years ago This can work in small environments, but on busy machines where numerous users are performing administrative tasks that require root privileges, it becomes difficult if not impossible to tell which "root" ran which command. In larger environments, this is essential. ### Re:It's all about logging (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago sudo bash any subsequent commands dont show up in the log ( from my experiance with ubuntu ) , so all they can tell is you went into a root shell, not what was done ### Re:It's all about logging (1) This comment was hidden based on your threshold setting. #### jZnat | more than 7 years ago Dude, I think you ssh'd into my machine and read that out of my log files! :( ### Audit Trails (1) This comment was hidden based on your threshold setting. #### quan74 | more than 7 years ago One word (ok two words) - Audit Trails. If *everyone* has root's password, you have no audit trail of who used it, at what time, etc. Sudo access gets logged, both the command and the user calling it. Granted if their intent on accessing the system was malicios they'd have the power (as root) to modify the logs, but if you are remote logging, or if their intention wasn't "purposely" malicious you'd have a trail. IMO the best practice would be to keep the root password a closely held secret, and give other users requiring root access sudo, and possibly remote syslog to a machine those users don't have root privs on. ### Re:Audit Trails (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Remote logging helps, but may not help in tracking down a malicious attack. Since it only logs commands, you could run a script called "update_sql" that actually installs a cron job that would nuke the system in two days. The lesson is that you shouldn't give sudo to someone you wouldn't also trust as root -- it's more of a protection against stupidity than anything else. ### Turn Off Remote Root (3, Informative) This comment was hidden based on your threshold setting. #### Erwos | more than 7 years ago Whatever you do, DO NOT allow remote root logins. Ever! root is the one account that attackers can be reasonably sure exists on your computer. Allowing remote access to it allows them to hammer it with dictionary, brute force, and social engineering attacks from relative safety. If you're the only admin on the computer, su into root is fine - if anything goes wrong, it's your fault anyways. Otherwise, use sudo to maintain high levels of auditability and least privileged access. -Erwos ### Re:Turn Off Remote Root (1) This comment was hidden based on your threshold setting. #### libra-dragon | more than 7 years ago I'm lazy and like to scp files as root --it helps adminstration. I guess you could just rename the root account to keep remote logins. I've never tried this, but I wonder if there's any flavors that have a specific dependency on the actual UID 0 being named "root". With that said, you could do what others mentioned and create duplicate UID 0 accounts. If you're needing remote root login, set PermitRootLogin to "without-password" and use keys. I know key administration is a real PITA, but it's easy if you have a utility server that you can use as a jump host for root logins. Keep the root private key on the utility server and hop from it when you need root (remote) access. This way all of your root key management is done in one place. Another lazy thing I do is "sudo su - root -c bash". This works best when the NOPASSWD option is used in sudoers. This of course blows away logging, but you can still see who's logged in... While we're on the subject of security... Keep your email addresses and your logins different. I've run across so many people who have their email address listed in their whois technical contact info and this just so happens to be their unix username as well. Don't make it easy for brute force attackers by giving them your username. ### Re:Turn Off Remote Root (1) This comment was hidden based on your threshold setting. #### WasterDave | more than 7 years ago I agree, with one exception. On development+gateway boxes it's good to be able to do ssh -Y as root so you can start ethereal as root and see WTF is going on with the network. If you ssh in as yourself the su over to root you lose the X11 tunnel for reasons I don't have the time to investigate. If there's a cunning/easy way around this, I'm all ears! Dave ### Re:Turn Off Remote Root (1) This comment was hidden based on your threshold setting. #### kestasjk | more than 7 years ago If you're talking about corporate environments with multiple admins then fine, but at home I allow remote root access, and as long as you have a secure password you'll be fine. No remote root logins ever, in big caps, is too much of a generalization. The accounts you have to watch out for are the ones which you might not think of, if you check your auth.log for attacks (I get one every couple of days) you'll see them attack accounts like 'test', 'admin', 'ftp', etc (and root too of course). They go for the 'forgotten' accounts. The difference is anyone will know to keep a secure root password, but most people will be less sure about whether their ftp account has a password, or whether they removed that test account they installed, etc. ### yes, use your powers for good (1) This comment was hidden based on your threshold setting. #### steveprice | more than 7 years ago Alias sudo to su, place the new su in their path first. When they figure it out, they've earned the right to use su! But by then they should be grown up enough to sudo. ### Re:yes, use your powers for good (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Spoken like a true BOFH ### Textbooks (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Well, if you ask the publishers/authors of The Linux+ Guide to Linux Certification (Second Edition), you should be running EVERYTHING as root. Doing ls? Root. Writing a little shell script that prints "HELLO WORLD" on the terminal? Root. Using X? Root. Surfing the web? Root. Seriously, the authors of this book need to be shot. And so does CompTIA for endorsing it, but CompTIA sucks at everything anyway. ### Audit trails (1) This comment was hidden based on your threshold setting. #### DarkFyre | more than 7 years ago Not only does sudo log what commands are executed, it tells you who executed them. This is useful even in day-to-day use when you do something silly. But in corporate environments, this is a necessity. If your company falls under the provisions of the Sarbanes-Oxley act, you are legally obliged to have this audit information. I know it's convenient to log in as root, but convenience mixed with privilege mixed with production systems is going to lead to unhappiness in the long run. Suck it up and disable root logins (and configure sudo to prevent your lazy users from running shells). ### Regulatory compliance in general (1) This comment was hidden based on your threshold setting. #### Beryllium Sphere(tm) | more than 7 years ago >under the provisions of the Sarbanes-Oxley act, you are legally obliged to have this audit information. REAL important point. It's not just SOX. Under HIPAA, I seem to remember that shared accounts are illegal. You may also be subject to some contractual restrictions, like VISA's PCI or CISP or whatever they call it this year. That may also decree "no shared accounts". >configure sudo to prevent your lazy users from running shells which is of course good advice but gets interesting pretty fast when you think of all the programs that have shell escapes. Not completely impossible, though, and it shouldn't be hard to find example /etc/sudoers configurations. ### Got Root - Need Root (4, Interesting) This comment was hidden based on your threshold setting. #### Ajehals | more than 7 years ago (Disclaimer, its 3 am, I've just given up doing a code audit on the basis that I am too tired, so if this doesn't make sense, I am sorry, oh and don't take my advice or even think about relying it the following statement is as is, and comes with no warranty - would be first post but its taken me half an hour to write this.. :) ) When you are logged in as root you have unlimited access to all files, and it is possible to remove or modify a file that is vital to the system, this is generally not good, and often not required. If you set up a server securely you should be able to create accounts that have the access that you require to carry out specific tasks (still preferably using sudo, or su'ing to the relevant account), this is as much a common sense measure as pure security precaution. You could argue that you can log in as root as long as you avoid using wild card designators when executing commands and keep track of your current working directory and try not to mess anything up, but there are a load good reasons to use sudo or su to root (or preferably an account specified for a task) instead, here are the ones I find most important: Firstly you get some accounting, if Joe Bloggs su's to root and breaks / steals / misconfigure's something, at least you know it was Joe Bloggs (or someone using Joes account) Secondly if you have remote access only as a non root user (this should be a given, never log in via ssh or webmin or whatever as root, (it can be a nightmare when you think your on system A but are on system B and do something you didn't mean to, never mind as root...) any attacker is going to have to find a non privileged account to gain access to a system, and then gain root privileges.. Thirdly if you have set up a number of administrative users for specific tasks you can compartmentalise your systems maintenance and you don't have to give someone you don't trust root access to carry out basic maintenance. Lastly, the less you use your root account (directly or by whatever means) the less likely you are to break it. Lets be honest, I'd love to log in as root all the time, it would make life easier, but it would get rid of quite a few of the security benefits Linux/Unix brings and I'd probably break things more often. If you get used to using the root account you will continue to use it more and more until you find yourself logged in as root surfing the web whilst playing some bzflag beta just waiting for someone or something to break your box. (not to mention the hours you would spend making it possible to log in as root and use all your apps that are (probably) not going to like being run as root). Personally when I set up a secure server I try to ensure that I have users with the relevant rights set up for specific tasks and no more and only issue those accounts to users who require them. I mount as many of the file systems as possible read only, I try to ensure I ship log files out to a box that no-one with root privileges on the first box has access to, and I automate as many of the maintenance tasks as possible. Oh and I don't use sudo, and on hyper critical servers the full root password is known to no one, I have half my oppo has the other half, and never the two shall meet (although this causes inconvenience when you do need it...!!) This prevents foul ups and gives you a security baseline. Oh and if you do log in as root make sure its not ever into a Desktop Environment (or any complex environment really) because there are just too many apps executing as root at that point to keep track of properly, and way too many potential security vulnerabilities... ### Re:Got Root - Need Root (1) This comment was hidden based on your threshold setting. #### lengau | more than 7 years ago When you are logged in as root you have unlimited access to all files, and it is possible to remove or modify a file that is vital to the system, this is generally not good, and often not required. What are you talking about? When has anybody eveer needed /vmlinuz? ### I have root, and love it (0) This comment was hidden based on your threshold setting. #### Gothmolly | more than 7 years ago I wrangled root for the ~7 servers that I'm directly responsible for, and use it all the time. The first thing that I do was re-enable direct root login. Now, the sudo fanboys and "best practice" fags out there will cry about this. But try running a redirected X session after you've lost all your X authentication info, because you're at least 1 'su' deep. I run my APPS as non-root, because I don't want an unattended session or process barfing all over the place, or filling a FS, or offering a remote hole to someone and providing the keys to the kingdom. but day to day stuff, tailling log files, etc.? Root is the only way to go. ### Re:I have root, and love it (1) This comment was hidden based on your threshold setting. #### run4ever79 | more than 7 years ago Looking at log files! A group policy can accomplish this without giving someone the keys to the kingdom. The OP was about allowing coworkers to have root access. You might not do anything deleterous yourself, but one of them might and *gasp* set you up to go down for it. ### Re:I have root, and love it (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago 1) What real unix admin needs anything more than a shell? 2) If you want to be root all the time, just stick to Windows. 3) There is no *good* reason to su or login as root. sudo is everything you need - set your systems up right and get over it. Sticking to root is just being LAZY. ### Re:I have root, and love it (1) This comment was hidden based on your threshold setting. #### atriusofbricia | more than 7 years ago Wow, I'm glad you're not on any box I have authority over. Your account would be locked within the hour. Besides, if you can't figure out how to get a redirected X session working having su'ed, do you really need root? Given that disabling direct root login is pretty much the first step done in securing any box, and pretty much everyone in the world agrees with that... Maybe you're the one that's wrong. On the other hand.. maybe you're trying to be funny. God I hope so. ### Not the right response (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago This probably isn't the response you're looking for, but if you can't trust the people to login with root, don't give them the sudo command. If you trust them with root, then stop worrying about remote logins, as long as you don't allow telnet/ftp or any other network login with a non-encrypted password stream. If you don't trust your users, then you want to see what they execute as root and keep logs...which is downright silly to me. I guess if you have an environment that must be VERY secure and have audits on everything...such as systems that do financial transactions, then auditing/limited root commands with sudo is a great idea. But if you have sysadmins and you don't trust them getting on the general boxes as root, then you better not give them sudo. Thats just my take on it. I personally login as root on all of my linux installs and find it silly to install a desktop and login as non-root. Yea yea, I know...lots of flames here on top security and what-not, but I could care less about security on my desktop system. I'd like to hear of cases where someone logged in remotely using ssh as root, and it caused a problem that couldn't have occurred with an unrestricted SUDO setup (note that I said unrestricted). SUDO, in my opinion, creates a lot of hidden security holes. When you give people SUDO rights, you better know damn well what each program they execute does inside out. For instance, vi can execute a shell. So can more or less. the IFS can be changed on many operating system to cause a program which has root privilges to changes things like system("/usr/bin/echo") to system("usr bin echo")...meaning if the program "usr" is in the path, it would get executed as root, allow a shell to be created. So SUDO is a very bad thing if you haven't reviewed the source code of every program you allow to be executed with sudo. ### Using Root. (2) This comment was hidden based on your threshold setting. #### run4ever79 | more than 7 years ago There is an expression that goes way back, "The amount of time that you spend logged in as root is inversely proportional to your competence as an admin." Once a machine is configured, there are only a small number of legitimate reasons to login as root, and nearly all of these can be more safely done using sudo as others have mentioned. For a good treatment of this see: http://www.theregister.co.uk/2006/02/24/bofh_2006_ episode_8/ . Also as previously mentioned root should _NEVER_ be able to login remotely. You might as well set up your DNS to name your box pleasehackme.domain.com. (Although you can rename the super-user account, which can be tricky to do right). ### Been using sudo since forever.. (1) This comment was hidden based on your threshold setting. #### Agilo | more than 7 years ago I've been using a user account and "sudo" since my learning days (some years ago) and I feel it's very good practice. I "su" only when I actually need to (not that often, mainly when I do a lot of maintenance i.e. kernel upgrades and the likes) which is, in my opinion, the way people should be doing it. ### Depends... (1) This comment was hidden based on your threshold setting. #### SanityInAnarchy | more than 7 years ago If your system is mostly stable, and you'd mostly be running a bunch of scripts from root anyway, then you might like sudo. It'll give you the logging, and if the scripts are secure, you aren't actually giving up root. However, most of what I do, I don't currently have such scripts. They wouldn't be hard to write, but I'd have to keep updating them, and there's too much that I constantly like to tweak. Thus, while I stay a normal user most of the time, I use root for admin stuff. That said, I have started to drop privelages for certain things. For instance, a "webmaster" account to manage the webserver, along with per-site user accounts, just makes sense. But again, that depends on your situation. Do you have a lot of highly specialized admins, or a few damn good general ones? If your admins are specialized, there's no reason the web admin needs access to the mail system, or vice versa, and neither should get root. If your admins are generalized, sudo (or user accounts) will probably just end up getting in their way. Take a good, hard look at your own situation and decide for yourself whether sudo makes sense for you. ### Sudo for me (1) This comment was hidden based on your threshold setting. #### ClamIAm | more than 7 years ago Mostly because I use Ubuntu and still suck enough at unix to not care. ### depends on your setup (1) This comment was hidden based on your threshold setting. #### bonezed | more than 7 years ago at work I log into our dev servers mostly as root but anything open to the public does not permit root login, plus has other restrictions in place ### rm -f (1) This comment was hidden based on your threshold setting. #### Spazmania | more than 7 years ago Ever done an "rm -f file. *"? Yes, that's a space in there after the dot. Added by a mistaken reflex. Oops. Do that as a normal user account and its bad. Do that as root... Well, do you wanna spend the rest of the day rebuilding the machine? Now, on the sudo vs. su argument I personally favor su. When you have to explore a problem with the service down until its fixed you don't want anything slowing you down. Try something as simple as "sudo ls /var/spool/mqueue/q*". Doesn't work. It tries to expand the wildcard as your normal user account which doesn't have access to the directory. It just makes more sense to su and then go exploring. But you don't do that in every window; you only do it in the windows where you're intentionally performing systems administration functions. ### Re:rm -f (1) This comment was hidden based on your threshold setting. #### nwanua | more than 7 years ago You know the funny thing about the rm -f thing? These days, it does more harm when I'm logged in as myself than when logged in as root: When I sudo into root, I am typically in some sub-directory (ie. /usr/local, /etc, or /var). A badly written rm -f removes parts of my system sure, but my home folder is usually unnaffected. An hour tops to restore stuff. However, if I were to make the same mistake any in my home tree (which is where I normally am when not sudo or root), I've lost a crapload of hours of personal work. So for personal machines (and a lot of us are running our own personal unixen these days), I'd argue that one is more likely to actually do some real damage (albeit to your stuff) as a regular user than as root (or sudo) Just a thought.... ### sudo means no password sharing (2, Interesting) This comment was hidden based on your threshold setting. #### shift | more than 7 years ago I hate coming into a place and finding out that passwords for accounts like root are shared. Its also a real pain when someone leaves the company. Where I work, we've basically tossed out the root password and grant access with sudo. We just have to disable accounts when someone leaves and not scramble to change a password then make sure every who needs to know is notified. ### Sudo, Generally, But .. (3, Informative) This comment was hidden based on your threshold setting. #### hbo | more than 7 years ago I use sudo routinely, for many of the great reasons outlined above. But how do you do egrep '^From: Postmaster' /var/spool/mqueue/qf*" with sudo? You don't. Globbing is broken because the shell does it before sudo is run. This gets around the problem: sudo "sh -c '(cd /var/spool/mqueue;egrep ^From:\ Postmaster qf*)'" That works, but it's ugly, and I have to be able to invoke the shell with sudo in the first place. I/O redirection is similarly broken. sudo grep root ~/cron_jobs >> /etc/crontab will fail because your shell will do the I/O redirection, not the sudo enabled grep. This works: grep root ~/cron_jobs | sudo tee -a /etc/crontab >dev/null This time, tee is the one appending the output, not the shell. I use these workarounds with sudo quite a lot. It seems I need the latter more often than the former. But I stick with sudo regardless, for the shell environment consistency, and the ability to go back and see what I did wrong 12 hours after the 36 hour hacking session ended. ### Re:Sudo, Generally, But .. (1) This comment was hidden based on your threshold setting. #### shish | more than 7 years ago But how do you do egrep '^From: Postmaster' /var/spool/mqueue/qf*" with sudo? sudo -s egrep '^From: Postmaster' /var/spool/mqueue/qf* Ctrl-D All the power of a root shell is still there, it's just easier to not use it~ ### root vs. sudo (1) This comment was hidden based on your threshold setting. #### ravenoak | more than 7 years ago IMHO, root should be limited to login on an actual tty (with a very secure password, nothing less than 13 characters, alpha-numeric with special characters) and use sudo for everything else. Like a lot of other people have said, sudo is rather powerful. Using sudo enables you to limit the commands that a user can run as root, including creating several groups of users that can run different sets of commands, and leaves an audit trail. Granted, all of that might be over-kill for a one-person operation at home (any sort of critical environment should use sudo to it's fullest, and business == critical), but I still use sudo for my personal machines because I believe it to be good practice, I just don't use all of sudo's functionality. ### Why do they have root? (2, Insightful) This comment was hidden based on your threshold setting. #### NNKK | more than 7 years ago If they're not a sysadmin, they don't need the root password. They probably don't need sudo, either. If they have the former, your internal policies are broken. If they have the latter, you better be damn sure of why. sudo is far from foolproof. It's almost exactly like making select binaries suid root and available only to a specific group, except that it's more convenient (good), and introduces an extra suid root binary that could have a security bug (bad). If they are a sysadmin, and we're talking production servers, they're either qualified to decide what's best for their particular situation, in which case you really don't need to be questioning them (if their judgement isn't trustworthy, what the HELL are they doing in a sysadmin position?) and you're just wasting everyone's time, or they're just generally incompetent, in which case either the IT department will eventually be taken over by someone competent and the house will be cleaned, or the company will die a slow and painful death. Either way, it's all pretty moot. Make sure your resume is up-to-date. ### Root is tempting (1) This comment was hidden based on your threshold setting. #### SlappyBastard | more than 7 years ago But you have to fight Satan and accept that some practices are for the better. For me, root was more bad habit from tinkering with Linux before delving into servers as a real world business. Especially when you're learning on your own, anything but root feels like being in a full body cast. But, once you learn and grow up with it as a business, you recognize that it's just poor practice to have root access sitting there begging you (and others) to cause havok. Look at it this way: how beautiful would the world be if we could restrict Windows users as easily? ### It comes down to experience... (1) This comment was hidden based on your threshold setting. #### ZackStone | more than 7 years ago I have 12+ years of *nix admin experience. During these years I worked together with many administrators of various experience levels. If I can note one correlation it would be that those lacking in admin experience tend to log in as root more often (if not always). One reason is out of an unconscious fear that something won't work and they won't be able to figure out what. Many of the above posts advocating root login/root all the time seem to display similar characteristics. The real question is whether there is both a 10+ year and an experienced sysadmin out there who logs in as root all the time? Chances are give enough time and experience one will learn one way or another all the many reasons why all root all the time may not such a good idea? PS. One more question for the road? How may out there are brave enough to do "rm -rf *" (even after a pwd) as root? ### Re:It comes down to experience... (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago I have been a sysadmin for more than twenty years, and still mostly use root. I see the point of sudo, but if I'm trying to figure something out, it's a hassle not to be able to "cd" because "sudo" runs commands in a subshell so a "cd" doesn't have any effect on subsequent commands so I have to type full pathnames for the logfile I'm tailing or whatever (and running a shell from sudo defeats the purpose!). Anyway, I don't use root unless I really need to. And I do type "rm -rf *", but rarely, only after doing "pwd", and even then stare at it for a minute before hitting enter. ### Brave enough? (1) This comment was hidden based on your threshold setting. #### RobiOne | more than 7 years ago Heh, how many are brave enough to have this alias: d='\rm -rf' and use it in all your accounts? Think. Then Act. No Problem. ### Re:It comes down to experience... (1) This comment was hidden based on your threshold setting. #### r00t | more than 7 years ago You can have more than one login at the same time. You can change the window appearance to mark one of them as being special. Pick a font, text color, background color, title bar name... Log in as a regular user too, first, so you won't be tempted to abuse the root login. Log in several times as the regular user, as needed to ensure that at least one will always be at a command prompt. As for "rm -rf *", I'd never do it because it's a silly command. It would leave you in an empty directory. Go up a level first, then use the directory name. ### sudo (1) This comment was hidden based on your threshold setting. #### yagu | more than 7 years ago I am the ONLY administrator, and mostly the only user of all and any of my machines and for various reasons I do virtually all root activity via sudo. When I began building a home network (mostly by collecting odds and ends of old computers and connecting them) and built them up with linux I found myself automatically using sudo because that was the way I did it at work. And I found reasons that made sense in a work environment also resonated at home even in a one-user universe. Auditability was reason number one for sudo at work. There was a lot of trust and there were more than one or two who had full sudo priveleges but it was handy to know who was using sudo, when, and what for. At home auditability is less an issue since it's virtually singular I'm the poser. But it is still nice to see the track of activity in syslog when you start wondering, "Did I really do that crazy thing thats f***ed up the system?" And, just plain pragmatism was the second reason for sudo. IM(NSH)O I'm a pretty darned good admin, and know the ins and outs of all Unix flavors and can be as aware and cautious as the next person. But it only takes once as root to do something really stupid before counting to 10ms. I would rather have a command NOT do something when I inadvertantly forget to sudo a command than inadvertantly do something because I issued the command as root. Nuff said. ### Depends on what I'm doing (1) This comment was hidden based on your threshold setting. #### miyako | more than 7 years ago IANASA (I am not a system administrator), but on my own boxes I tend to use sudo if the task I'm doing only involves a few steps. If I'm doing something that requires more than 4 or 5 commands, then I tend to su - ### At least one exception (1) This comment was hidden based on your threshold setting. #### Theatetus | more than 7 years ago I can think of two exceptions: never ever run vipw or visudo through sudo. Always run it through su, log in separately and test that the change you made does what you want it to, then log out of your su shell. I can't tell you how many thousands of dollars I've charged my hosting clients to undo a passwd or sudoers change they made using sudo and screwed up. ### Who needs sudo? (0, Redundant) This comment was hidden based on your threshold setting. #### RoadWarriorX | more than 7 years ago echo "Who needs sudo? Well, I am not too sure." >> message.txt echo "It's not like someone can do something that harmful." >> message.txt echo "Maybe it's just an overreaction. It's not like I am doing" >> message.txt rm -rf *.* >> message.txt Oh crap. ### LEARN FROM EXAMPLE! (0) This comment was hidden based on your threshold setting. #### Anonymous Coward | more than 7 years ago Let me tell you a story about an admin who had the habit of logging in at the console of a server as root. And running then-hot SunWindows package. Worked like this all day long. In some windows would su to their own account to check email. Now one day this admin was in the WRONG WINDOW when typing rm -rf * The remaining hours of that day/night were spent retrieving files from 9-track backup tape. Yes that was me about 1989, on the console of a Sun 3/160 server with SunOS. I am still a sysadmin, but never again do I login as root as a matter of course. ### It sounds like you are not really using sudo (2, Funny) This comment was hidden based on your threshold setting. #### Error27 | more than 7 years ago It sounds like you can't really articulate a need for sudo but you're just doing it because you read about it. Sudo isn't magically better if you don't use the features. Also it annoys me that sudo seems to have a lot of security bugs. It had 3 local exploits last year... That doesn't affect whether you should use it or not because you obviously should, I'm just saying that it annoys me. ### Sudo's intended use (2, Interesting) This comment was hidden based on your threshold setting. #### RomulusNR | more than 7 years ago Sudo's main benefit IMO is to keep unattended terminals and non-password-based attacks from being no-brainer vectors to root. It's not to make it a pain for you to have to type a password just to run root commands; its to make it so that the user is able to run certain root commands and making extra sure before doing so that it is really that user running them (not a hijacked terminal, etc.) The other benefit is that it allows you to pick and choose who needs access to what root privileges. Junior data center tech A doesn't need access to fsck(), but maybe needs to be able to mount /dev/sdc. (OK, poor example.) Sudo isn't IMO the solution for all admins, though; extensive admin work quite necessarily can be done with su to root instead. Sudo allows you to keep the root password on a tight leash -- preferably to those who can be responsible with their sessions as well as with root powers. ### My two cents on sudo (1) This comment was hidden based on your threshold setting. #### xmas2003 | more than 7 years ago 3 categories of admins. 1. Admins who don't have a clue and don't know about sudo so they just login as root. However, if you tell them to use sudo, they are mallable enough that they will listen and do so. 2. Admins who haven't been around a while, but think they know a lot, and therefore insist that sudo is OK for them for a variety of reasons. These folks often won't listen to 'ya. Dangerous! 3. Admins who have been around for a while and insist on using sudo. If you bring 'em into a new environment, it's the first thing they will install if it doesn't exist. They realize it's a good thing and want to have everything they have done logged ... plus all the other reasons enumerated elsewhere. BTW, Todd Miller has graciousely maintained sudo for years - consider tossing him a few dollars to continue working on it. ### root or root not; there is no try (5, Funny) This comment was hidden based on your threshold setting. #### Tumbleweed | more than 7 years ago Look, if you're too much of a pussy about using root because you might screw something up, you shouldn't have the root password anyway, should you. *pbbt* :) ### Logging Who's On. (4, Informative) This comment was hidden based on your threshold setting. #### Stephen Samuel | more than 7 years ago If you've got a half dozen (or dozens of) people who have root login, and something goes on, all you have with a quick look at the log is that someone logged in at 4:15 pm and the system choked at 4:18. If you force people to login as themselves and then SU (or sudo), then you know who was on the system with root when the system snarked ( And, if they use sudo instead of su, you can even have logs of the commands they used) -- it cuts down on the number of people you have to interview in the rush to figure out what broke the system. Then, there's also the fact that if someone tricks you into doing something 'bad', it's less likely to catch you flatfooted as root if the only commands you exeute as 'root' are the ones that really need root. As a last point: If you disable root logins (especially remote root logins), then a hacker needs to hunt down two passwords to get root access -- one for remote access and the other to get root. Security isn't about making it impossible for an intruder to get in -- It's about making it hard enough that an attacker gives up and goes away -- even if they just go find an easier target (hi bill!). ### Audit trail (4, Informative) This comment was hidden based on your threshold setting. #### horatio | more than 7 years ago In addition to the things the parent mentioned about privilege seperaration and permissions, sudo (if configured correctly) gives you an audit trail of what was done by whom and when. If someone fscks the database server, you'll know exactly who to beatdown and where to look for a restore point in your backups. Apr 16 01:30:30 karma sudo: joeuser : TTY=pts/0 ; PWD=/home/joeuser ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log It will also let you know if someone is trying to do something you haven't authorized for them in the sudoers file. On systems where I'm the only user, I almost always use a non-root account to do normal tasks. sudo lets me elevate privileges for the command I need to, ie$ apt-get install reallycoolwidget
, and then drops back down so I don't forget to exit myself. sudo (generally) does not require you to retype your password for every command, there is a timer. If you're dumb|busy enough to walk away and leave your terminal unlocked, after a few minutes the next sudo attempt will ask for your password again.

One thing to remember, use visudo, not vi /etc/sudoers. The syntax check will likely save your ass one day.
Slashdot Account

Need an Account?

Don't worry, we never post anything without your permission.

# Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

• b
• i
• p
• br
• a
• ol
• ul
• li
• dl
• dt
• dd
• em
• strong
• tt
• blockquote
• div
• quote
• ecode

### "ecode" can be used for code snippets, for example:

<ecode>	while(1) { do_something(); } </ecode>
Create a Slashdot Account