james hughes wrote:
>
> This is not about the elimination of root as a much as it is the ability
> to create a machine that has a no root password. Previous methods of
> having root have a password are still possible. In 2008.05, it is
> possible for the initial user to type "pfexec passwd -N root" and
> continue on their way simply typing "pfexec bash" instead of
> "su"/password combination. My motivation was that asking for the
> password at installation was a needless step because of the above. The
> bug was that if you eliminated the root password and wanted to get
> single user, it was not possible, hence the case.
>
> If the target market is Linux web 2.0 developer. The application
> developers I know of (personal experience included) rely heavily on
> sudo. In addition to other OSs like Ubuntu, Mac OS X also runs without
> the root password. (People that are developing the Linux kernel
> typically run as root and are not the target IMO.)
>
> With this change web 2.0 admins can do "pfexec bash", "sudo bash" or add
> a password to root. (IMO, we do need at least a redirect of people
> typing sudo to pfexec and a longer term plan around sudo, and we should
> think about doing this in general. I believe Ubuntu has the ability to
> suggest packages when unknown commands are typed in.)
>
> Longer term, it is another password that the developer does not need to
> remember, change and manage.
>
> Enterprise admins have more issues as Bart suggests, but they are more
> motivated to eliminate the management of shared root passwords and their
> human processes. This change does not eliminate how enterprises are
> doing it now.
>
> Bottom line is that it results in simpler installation, simpler
> management and similar administration (to Ubuntu and Mac OS X) and does
> not break the existing paradigm. For we RHEL developers this hurdle is
> not significant.
There's another way you might solve the same problem and achieve some
other benefits simultaneously.
1. It would be a lot simpler and more convenient if role accounts didn't
require passwords at all. The only reason they have passwords is that we
needed the role accounts to be able to act as NIS+ principals, and that
requires a credential that is generated from the account login password.
If we could find an alternative way to generate that credential (or
declare that the ability to act as a NIS+ principal just doesn't matter
any more for a role account), we could make it more convenient to assume
*any* role and reap the attendant benefit of managing fewer passwords.
2. It still makes sense to have the root account be a role, so that
direct logins are disallowed and it is always possible to attribute
actions performed as root to an individual user. For single-user login,
however, you don't really need a new authorization. Instead, sulogin
could allow single-user access if the user authenticates and is allowed
to assume the root role. [I'd recommend this modification to the
existing proposal in any case; the ability to assume the root role
should be a valid substitute for the solaris.system.maintenance
authorization.]
Adopting both of the suggestions above means that
* root actions can always be attributed to a real user
* assuming a role is more convenient for users
* fewer passwords need to be remembered, updated, etc.
Scott
