Got Root - Should You Use It? 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?"
Simple solution (Score:2)
Re:Simple solution (Score:3)
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
Re:Simple solution (Score:4, Insightful)
Congratulations. You have now completely removed almost every reason for using sudo in the first place.
If all you use sudo for is starting a root shell once you've logged in, then save yourself the hassle and just login as root, because you're circumventing basically every benefit sudo offers.
Re:Simple solution (Score:3, Informative)
Unfortunately once someone gives the sudo su command all you see in the logs is an indication that some grabbed a root shell. I guess that it's a matter of personal preference, but I like the sudo method. I do login as root on occasion, but I like the extra warning that I might be breaking something with a chmod or mv.
Sudo wins for me (Score:5, Informative)
Root (Score:2, Insightful)
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 (Score:4, Informative)
Re:Wrong (Score:3, Interesting)
All normal database admin can be done with various programs that access the server remotely (by which I don't mean ssh!). Abnormal admin that requires actually logging into the server pretty well always requires root. The same goes for everything else.
It is true that the daemons should not RUN as root but by and large every one of them needs root to do anythin
Re:Wrong (Score:3, Informative)
> I don't mean ssh!). Abnormal admin that requires actually logging into the server pretty well always
> requires root. The same goes for everything else.
> There's just no need to be on your server unless you are root.
Hmmm, i've got to disagree. What database product are you thinking of?
I'm using db2 to manage a large data warehouse & set of reporting databases. DB2 is notorious for requir
Re:Root (Score:2)
Some people actually do development work logged into a remote server. In such cases it's simply good practice to have a separate login for each user. Of course, maybe the particulars of your situation don't require this--but your assertation implies that it's adequate for everone, which it certainly is not.
Re:Root (Score:2)
I don't know about SVN but Oracle has applications which allow remote DB admin without granting shell access to the actual server.
No user should get a prompt on your server if you can avoid it. If you can't then obviously you'll have to give them a login account, but it's much better to not have users accessing the server directly if you can manage it.
TWW
More than just root (Score:5, Informative)
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
When I'm not using sudo and I do 'cd
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 (Score:3, Interesting)
And if (as with my current job) you work someplace with:
Re:More than just root (Score:2)
Re:More than just root (Score:2)
Re:More than just root (Score:2)
Re:More than just root (Score:4, Insightful)
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 (Score:3, Insightful)
Re:More than just root (Score:3, Informative)
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 bu
Re:More than just root (Score:3, Insightful)
So, what OS are you running?
Re:More than just root (Score:2, Informative)
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" [New File]
user/server:/path$ ls -l
Re:More than just root (Score:2)
That's me testing a cron script for eventual use and editing my spamassassin rules (yesterday). If I screwed something up, I'll what I did as root because sudo will log the command (look in /var/log). If anyone else did something, I'll know at 1AM when logwatch emails me the reports.
Re:More than just root (Score:2)
--Doing that while running the " screen " program is not recommended, and may cause unpredictable results.
Re:More than just root (Score:2)
sudo !!
Re:More than just root (Score:2)
You're in trouble anyway if the person leaving had enough privileges to do something like this:
cp
sudo chown 0:0 ~/bin/sh
sudo chmod u+s ~/bin/sh
It's pretty hard to put useful limits in sudoers...
Re:More than just root (Score:3, Informative)
Perhaps a nitpick, but be _very_ careful with that slight misconception. The correct statement would be:
Sudo allows you to grant root (or other) UID to specific users for specific commands.
On the surface it appears a slight distinction, but it means that seemingly innocent commands like vi or more lets users do shell escapes to obtain root shells, cat with sudo priviliges can allow them to overwrite passwd, etc.
Basically, while using
Re:More than just root (Score:2)
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).
Sudo (Score:5, Informative)
sudo is all wrong (Score:3, Insightful)
Plain old su works well. It leaves a log, via the shell history file. You can adjust the history file size if needed. If you want a secure and uneditable log, neither will do. Breaking out of sudo is easy; normal command-line software is not designed to keep you in the setuid-like environment that sudo provides. Regular old apps will have buffer overflows, which are not considered security holes... until you
if you're in an X session (Score:2)
alias su="xterm -fg white -bg darkred -e su"
I stick to sudo (Score:5, Insightful)
Re:I stick to sudo (Score:2)
I personally stick to sudo. The main reason why is to protect me from myself, more than anyone. Because I have to prefix the command with sudo, it serves as a 'mental brake' to slow down my typing, and double check what I type before I run it.
(Quoted for Emphasis) (and bolded, too)
Re:I stick to sudo (Score:5, Interesting)
It depends... (Score:5, Interesting)
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... (Score:2)
On my own machines, I
the second xterm (Score:2)
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.
Ask slashdot; (Score:5, Funny)
Re:Ask slashdot; (Score:4, Funny)
Re:Ask slashdot; (Score:3, Insightful)
P.S. you seem to have found an exception to my sig ...
Re:Ask slashdot; (Score:2, Funny)
sudo... (Score:2)
-S
ps hi joe!
It's all about logging (Score:5, Insightful)
Apr 15 22:05:41 linux-black sudo: matt : TTY=pts/0 ; PWD=/home/matt ; USER=root ; COMMAND=/usr/bin/tail
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 (Score:2)
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 (Score:2)
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 (Score:2)
Re:It's all about logging (Score:2)
$ sudo rm -rf
$ sudo rm
$ sudo bash -c 'echo "Apr 15 22:05:41 linux-black sudo: person_you_hate : TTY=pts/0 ; PWD=/home/boss ; USER=root ; COMMAND=/bin/rm -rf
$ logout
Yes, yes it is.
(Even if you syslog to a remote machine, we all know that UDP can never be forged... especially by root.)
Re:It's all about logging (Score:3, Informative)
you do, of course, realise, that this command will be appended to your freshly deleted log?
Turn Off Remote Root (Score:4, Informative)
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 (Score:2)
If there's a cunning/easy way around this, I'm all ears!
Dave
Re:Turn Off Remote Root (Score:2)
Well if you do "su" without a "-", it inherits your ENV but then your XAUTHORITY is messed up. Doing export XAUTHORITY=/home/`user I was before`/.Xauthority can solve this.
If you're doing "su -", the - overwrites your ENV with whoever you just su'd too, so you lose your DISPLAY variable(generally localhost:0.10 with -X/-Y).
Re:Turn Off Remote Root (Score:2)
You should consider using something else than ethereal. That program was removed from the OpenBSD ports tree due to bad security track (remote exploits) and authors unwilling to do something about it:
Re:Turn Off Remote Root (Score:2)
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 th
Re:Turn Off Remote Root (Score:2)
In a home environment I'd recommend moving your ssh server to a non-standard port. I did this a while back and have since had zero attempted ssh attacks. You can use the ~/.ssh/config file to remove the need to add the extra "-p 12345" option each time as well.
Cheers,
Roger
Re:Turn Off Remote Root (Score:3, Informative)
Unless you login via SSH with RSA keys
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.
Not if you're using RSA keys.
Whether to use sudo depends on your role within your organization. I'm the sole admin of a small company, so I use root. If something stupid was done, it'd come right
Audit trails (Score:2)
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
Regulatory compliance in general (Score:2)
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
Got Root - Need Root (Score:4, Interesting)
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 (Score:2)
As a matter of fact, no. I find grub's command line to be quite accomodating and featureful. When I don't have vmlinuz, I can just append
Using Root. (Score:2)
Re:Using Root. (Score:2)
The sysadmin at work did it for me on my workstation just by duplicating the first line of /etc/passwd and changing the username to my-root
Re:Using Root. (Score:3, Interesting)
Someone other than me deserves credit for this oh-so-true statement.
Depends... (Score:2)
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
rm -f (Score:2)
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
sudo means no password sharing (Score:2, Interesting)
Sudo, Generally, But .. (Score:4, Informative)
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 .. (Score:2)
sudo -s /var/spool/mqueue/qf*
egrep '^From: Postmaster'
Ctrl-D
All the power of a root shell is still there, it's just easier to not use it~
Re:Sudo, Generally, But .. (Score:2)
It's gone, as far as sudo is concerned. The contortions I describe, while a bit hard on the fingers, maintain the automatic record sudo makes of my rootly actions.
Re:Sudo, Generally, But .. (Score:2)
save as "from_postmaster" or something. run 'that' as sudo. Tweak accordingly. (I'm not absolutely sure it will work as written, but it should come pretty close, and is just an example
Why do they have root? (Score:2, Insightful)
If they are a sysadmin, and we're talking product
sudo (Score:2)
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 num
Depends on what I'm doing (Score:2)
At least one exception (Score:2)
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.
Re:At least one exception (Score:2)
If you use visudo, it does the _exact_ same checks as sudo does to the sudoers files before it allows you to write the file. Check the code.
If someone's telling you that they used visudo to edit the file, then saved, then tried to run sudo and it failed because of an error it
Re:At least one exception (Score:2)
Though visudo catches actual syntax errors (or at least ones that sudo spots), presumably there's nothing stopping you accidentally making some syntatically-valid change that locks you out of using sudo... or even (in theory) a syntactically-invalid change that visudo and sudo both accept for some reason.
It sounds like you are not really using sudo (Score:3, Funny)
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 (Score:3, Interesting)
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
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 (Score:2)
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 environmen
root or root not; there is no try (Score:5, Funny)
Logging Who's On. (Score:5, Informative)
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 (Score:5, Informative)
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 , 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
Re:Audit trail (Score:4, Interesting)
Doug Hanks, a SAGE member, started with sudosh (http://sourceforge.net/projects/sudosh/ [sourceforge.net]) and now has released Enterprise Audit Shell (EAS). There's a very basic web page and PDF at http://download.strchr.net/ [strchr.net], as well as a nice graphic explaining how it works (http://download.strchr.net/eas-layout.png [strchr.net]).
Copying from the text of the email announcement a few weeks ago, the list of improvements over Sudosh includes:
* Conforms to COBiT
* Utilized ITIL best practices
* Enterprise-view of UNIX access
* Enterprise-level audit reporting tools for Sarbanes-Oxley
* Customizable audit reports via CSS
* Embedded transactional, ACID-compliant SQL92 relational database
* Load balancing
* Disaster recovery
* SSL encryption
* SSL Public Key Infrastructure authentication
* Audit file transfers and remote command execution when used as a login shell
* Configurable default shels
* Audit logs are digitally signed for integrity
* Client and server configuration files for easy management
* Idle session timeout
* Display corporate policy before eash session
It looks like a serious auditing tool for serious Unix shops.
For simpler needs there's also Kerberos `ksu` as a replacement for sudo, for shops that have already solved their centralized authentication.
Re:Audit trail (Score:2)
Needs to be properly setup (Score:2)
If your /etc/sudoers is only a few lines long and basically does (and is used for) little more than allow users X, Y and Z get a root shell, then there's really little point to using it at all and you may as well just save the annoyance of having to run 'sudo bash', 'sudo su', 'sudo -i' - or whatever other incantation you use to get a
Sudo can backfire (Score:2)
Never give developers root ... (Score:3, Insightful)
Applications that *require* root access to even run and require sub-apps to be root as well. They are slowly getting better (but only because in the last few years we've enforced a policy of no root access to developers).
IMHO, root access encourages sloppy behaviour (in both developers and sysadmins) and it becomes an essential crutch rather than an 'only as needed' facility. With the focus on security, and the requirement to participate in regular security audits (SOX anyway?), it simply suicide to give developers root access.
Security of a normal Account (Score:2, Interesting)
Sudo weakens security (Score:5, Informative)
It seems that this is surprising to a lot of people because nobody has mentioned this, and people have mentioned that you should never allow remote root logins, yadda, yadda.
Actually there is no problem with remote root logins via ssh and public key authentication... just don't use/allow passwords. I'm continually amazed by how few people understand this, especially considering that practically everyone and their dog already uses ssh for everything anyway (except they use it as though it was telnet... doh!). Ssh is the best thing that ever happened to Unix security, but 99% of people, including sysadmins it appears, use only 1% of its power because they do not understand public key authentication. But I digress...
Passwords are almost always security's weakest link, unless you have truly exceptional password discipline (i.e. chose a good (long, random) pw, have a different one for every account, use it only in safe contexts, never, ever, ever share it even with your twin-sister-wife-best-friend, never write it down, etc). The problem with sudo, from a security standpoint, is that it adds the weakness of every sudoer's password to the root account. Think about this... the INSECURITY of your root account is increased by the sum of all the weaknesses and password in-displine of all your sudoers.
Let me say this again... with sudo your root account's password security is worse than the worst of the passwords of all the sudoers, it accumulates all the weaknesses, all the indiscretions of all your sudoers.
And don't give me any crap about limiting what commands a sudoer can invoke... with sudo any command/program that isn't specifically written to be a
To their credit most of the people who wrote here that they like sudo like it for the convenience of logging priviledged actions. This is certainly a good practice. Just understand that it is a PRACTICE, not a security feature... if someone wants to get around it, they trivially can. If you want to log for security you have to do it in the kernel and most Unix kernels have such features nowadays.
So, if you want convenient logging of your own actions, go ahead and use sudo. If you want to
Btw., some ssh implementations can do everything you
Re:Sudo weakens security (Score:3, Insightful)
It's not about the root access... (Score:4, Informative)
What does matter, is accounting for which user ran that "rm -rf /mnt/financialReports" and isn't owning up to it. Or which user made system tuning changes that don't seem to be working right. Or any number of things which may or may not be malicious, but need questions answered.
None of the companies I worked for put sudo on servers to limit what their sys admins could do - they put it on the systems so that they could, if something were to happen, figure out which of their admins they needed to go ask questions of. Files are missing, what were you doing. Server isn't behaving right any more, what was the last thing you worked on.
You can't do any of this (easily) if 5 admins are all logging in as the same user. You can do it fairly trivially if you're logging in as your own id and switching to root.
For me it is about passwords (Score:3, Informative)
Using su instead of sudo puts one more barrier in the way. If you cracked a regular user account with liberal sudo access but a weak password, the same weak password gets you to root. That isn't true with su.
Re:Use sudo rarely? (Score:5, Informative)
You are. The right way to say it is, "Use sudo if you only need to run one command as root; log in as root only when you're going to need to do a number of things that require root."
As a side-note, somebody upstream noted that sudo doesn't change your environment, but becoming root does. If you don't need root's environment, just use su, instead of "su -" and you keep your current location, $PATH and other things.
Re:Use sudo rarely? (Score:2)
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
Re:Use sudo rarely? (Score:2)
su -
you become root, in the same directory as you were in, without running root's login scripts. Of course, that means that you probably don't have /sbin on your $PATH, but if you're just installing software, you shouldn't need it.
Nah, viruses don't need root (Score:3, Informative)
Re:It comes down to experience... (Score:2)
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 firs
Re: (Score:2)
Re:SuDo? never.. (Score:2)
I was contemplating for 30 seconds how to moderate, but the scarcity of options just isn't flexible enough for "Wow, you're a clueless asshat!"
Re:SuDo? never.. (Score:3, Informative)
Re:I have root, and love it (Score:2)
Is it possible that real sysadmins perhaps understand the underlying mechanisms of xforwarding and set the oh-so-hard-to-research XAUTHORITY variable? Wait? It's documented? I never saw that in my Redhat Users guide!!!
Sometimes, though it might be difficult for you to understand, it might help to RTFM. Guess that's the difference between sysadmins and wannabe admins. Sysadmins occasio
Re:I have root, and love it (Score:2)
When using su, you have to type the root password and it is being sent over the network. Encrypted, sure, but more vulnerable to time analysis then a RSA/DSA key used to directly access the root account.