I think the purpose here is to provide the console user with some
authorizations/privileges so that he/she can run some admin tools
(e.g. gnome-sys-suspend, g-p-m, poweroff) successfully. Then there
are at least two questions to be answered:
1. Which admin tools should be provided to the console use? so that
which authorizations/privileges should be assigned to the console
user?
2. How to dynamically assign authorizations/privileges to the console
user?
For the second question, we may add supporting library functions (e.g.
console_role_login/console_role_logout, just like di_devperm_login/
di_devperm_logout for console devices permission) for login programs
(login, dtlogin, gdm) to dynamically assign required authorizations/
privileges for the logged in console user upon login/logout. Maybe
there are better ideas.
Another way to think about this purpose is that probably we can
add a supporting library function like is_console_user() for admin tools
which are identified to be used by the console user. Then these
admin tools may need to be turned into suid root programs or something
like that. This way requires the change to all admin tools, so it
doesn't look good.
Regards,
Riny
Lin Ma wrote:
> 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.
>
> 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
>
