I'm restarting this Fast Track for Jim Hugnes.
It requests a Patch release binding.
References to Major release bindings and permission to do things
at such a release boundary are no longer part of this case.
The Problem statement has been modified to reflect this.
The interface taxonomies remain unchanged.
The timer is set for 9 July, 2008
Gary..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Problem:
========
| Other operating systems that have implemented roles (such as
| Ubuntu, MacOS, Windows) have eliminated the need for a "root"
| to be a login account. Solaris's only remaining requirement for "root"
| to be a login account is sulogin(1M). Requiring "root" be a login account
| is an unnecessary imposition for simple single user machines (such as a
| machine used by application developers).
Background:
==========
Since SunOS 5.8, Solaris has had the ability, through rbac(5), to
administer the system without a "root" user login.
Historically, the "root" user exists as an "owner" of system objects.
(It would be possible to have system objects "owned" by different system
users. There may be marginal value in doing so. This project does not
propose changing system object ownership.)
Historically, running with euid of 0 granted full system access.
Since SunOS 5.10 Solaris has had the ability, through privileges(5),
to administer the system without requiring full system access.
The "root" (system) user can be controlled by making "root" a role.
If a site doesn't grant the role to any user, no user can become "root".
Alternatively, it was suggested that in other OS distros, "root" is,
by default, not an account that can ever be directly used. In SunOS
5.10 terms that would be a no login account (see passwd(1) -N).
It has been suggested that Solaris should permit "root" to be a no login
account.
Proposal:
========
Add a "solaris.system.maintenance" authorization. Modify sulogin(1M) to
prompt for a username and password. If the username entered is
authenticated by the password and has the "solaris.system.maintenance"
authorization, enter system maintenance mode. If not, as before this
project, deny access.
Notes:
======
This proposal allows for administrators to grant users system maintenance
mode access without giving them the knowledge of the "root" password.
+ The existing capabilities of "root" users or systems where "root" is a
+ login account is unchanged. Both the "root" user and any user granted
+ the Primary Administrator Rights Profile have all "solaris" authorizations.
+ Users without local accounts have no change.
+ Just as today, if an administrator has chosen to make "root" a no login
+ account in a zone, "pfexec /usr/sbin/zlogin -S" must be used to enter
+ that zone. The Zone Management Rights Profile contains "zlogin"
This proposal does not ensure that the authenticated username is not
a role.
The "root" user is by default granted all authorizations. So, there
is no regression if "root" is not made a no login account.
A no login account ("root" or otherwise) can still run cron jobs.
The solaris.jobs.admin authorization permits a user to manage all cron jobs.
Non-"root" users may be granted Rights Profiles or roles that permit
the users to administer the entire system.
The current authorizations in solaris.system space are:
solaris.system.:::Machine Administration::help=SysHeader.html
solaris.system.date:::Set Date & Time::help=SysDate.html
solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
This project enables a policy where "root" can never be used
directly by administrators as an account providing full system access.
