? 2007-08-17?? 10:05 +0800?Lin Ma???
> Hi,
> 
> Currently we can see there are lots of requirements in system user-level
> for identifying a console user especially in the scope of admin tools,
> e.g. gnome-sys-suspend, gpm, nwam, etc. I think those tools would like
> to give console user the priviledge to use them. I know now we have to
> check the owner of /dev/console to identify in each application if
> necessary. But to be Solaris RBAC compliable, we'd better to use an
> auth_attr like solaris.device.console[.session] or whatever.
> 
> So I think the best way is to hack login application (dtlogin, gdm,
> ttymon, etc). I've talked with Riny, he think all the login applications
> finally invoke console_role_log[in|out] to change the owner of
> /dev/console. If so, I think we can change those function to add the
> auth which I mentioned above to the login user. Riny told me if we have
> the requirement, we can set up a discussion to change those functions
> since they (Riny and his team) own them.

Another option that is more flexible and better is to allow the user can
change its role dynamically. This is also what gnome power manager
requires. Perhaps we can define a new "console" role which can perform
shutdown, suspend and network administration work. When a user starts
the application, a dialog will pop up and allow the user to input
another user name and password, so that the user can get the permission
of another role.
As I know, PolicyKit can meet these requirements if it supports RBAC.
You can get more info about PolicyKit from
http://webcvs.freedesktop.org/hal/PolicyKit/doc/spec/polkit-spec.html?revision=1.7
and working diagram from
http://webcvs.freedesktop.org/hal/PolicyKit/doc/spec/polkit-arch.png?revision=1.1
> 
> But here're some tech issues. Since all the changes happen in user
> land. So I take a quick look of /usr/man/man3secdb (note I'm not good at
> SEC), I found there are no functions supporting temporary change the
> auths of a user. But in one of them mentioned libsecdb has an internal
> storage (I guess I can say it cache) of sec related information for a
> user. Since permanently changing /etc/user_attr for a console user is
> not a good idea, so maybe we need assistance of security team to evolve
> them.
> 
> (We may make things complicate if we like. e.g. append a special
> role to a console user)
> 
> Is it possible? Comments?
> 
> lin 
> 


Reply via email to