Are you ready to give up the root access?

Just disable root login via ssh and su to root. Its always worked fine in any organization I've been part of. Just use console to login as root for maintenance, all other users just use sudo.

Will you give up the root account ? My experience show than mainly sysadmin have a personal relationship with the root account and have big problem to not hold the password of their own server.

If I am responsible for a server, I will need some level privileged access. It doesn't matter if this accounts name is root, or if I have to login as myself and use some tool to elevate my privileges.

If the system is a standard *nix (or close too the standard) then I will probably need the root access for some administrative task at some point or another, simply because this is the way it has been for decades, and there is lots of inertia in this way of doing things. But this doesn't mean that I would login as that account when I don't need it, or I would leave that account open and unprotected.

If I am not responsible for the host, then I probably should not be given the root account. In fact, I frequently try and avoid letting anyone tell me the what the root password is.

So if your IT infrastructure was completely redundant and the non-access to one particular server is non-critical and can be addressed by clustering, virtualisation, cloning, fast backup system, etc..

Honestly, I don't see how any of that relates to needing a privileged account to perform privileged tasks on a computer.

When capabilities are more generically supported across everything, absolutely.

Until then, I'll keep sudo around for the few things that still require explicit privilege escalation. Last I looked into it, though, the notion of capabilities was still relatively not supported in many systems out of the box. That would be important to have. That way, no matter what your system, you can say "This user has the capability to access this," without actually being escalated to another user account. Of course, the privileges granted would need to be based on the roles of the users in the systems, but eventually, nobody should hold all the power of the account (at least, not if there are multiple functions that others are employed to handle).

If you're a DBA, you don't need any form of superuser access as long as you own the database system process and filesystem storage area(s). That might mean that you have to ask the disk admin to fun fsck on your partitions or restore them from time to time, or whatever, but the DBA shouldn't have the ability to take down a machine with their own access rights, unless they “own” the server.

That said, if you're the only person managing 100% of the processes on the server, then sudo is absolutely sufficient. It's only when you have others that use the server and/or manage things on it (or depend on it) and there are multiple administrators that separation of privilege enters into account, anyway.

We still keep root accounts and login on all of our servers. The reason being that all other user accounts come from a central directory server. If a server was taken offline or somehow lost its connection to the directory, there needs to be a way to log in to it to work on it. I don't see how else this could be done other than having a root account.

Common best practices in organizations I've worked in regarding the 'root' account.

• Disable remote access entirely, or only allow SSH via key authentication.
• Disable/lock root's password (a la Ubuntu).
• Strictly require use of sudo and ensure it logs properly.
• Lock down /bin/su to only be executable by a certain group (often, wheel or sysadmin).
• Ensure that root shells are well logged (enforce script, use sudosh, shell history tricks, etc).
• Only users who require root access are granted rights to sudo ALL and rights are otherwise granted through sudo on a per-use basis.

UID 0 is still required, particularly for tasks like opening ports below 1024, even if privs are dropped after an app is running.

Security and convenience are mutually exclusive in IT. Using the root account directly is often a matter of convenience, not necessity, perhaps because admins hate typing sudo all the time?

On Unix and GNU/Linux, there are still times when you need to be root but not often. You can significally reduce the need to be root if you set up sudo, SELinux and/or capabilities correctly.

A wealth of information about failures is hidden in root-only log files, but given correct permissions setup to allow me at those same log files, and a test environment where I can be root if I want to, then Yes. I will.

If sudo lets me do what I need to do -- and sometimes I need a root shell -- then yes, I'd give up the root account. I'd probably be happier that way, actually.

My answer is simply "NO". Of course the root account is used whenever I need administrative rights, otherwise a normal user account is to be used.

As a MS Windows developer, I had been always using a domain account with local administrative rights. Otherwise there is too much trouble, especially when you need to deal with COM/COM+, etc. I had tried to develop using a normal user in the early days of Windows 2000 and gave up finally in a month of time... "RunAs" cannot save all the trouble for me at that time...

Most of the environments I've worked in the last few years have the root password in a password safe to be used for emergencies, and for all privileged access to go through sudo or ksu. Not only does this allow more fine-grained access control but has the side effect of maintaining an audit trail - you can tell which non-privileged account escalated to execute which command.