Riny Qian wrote: > 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? I'm not sure. Admin tools developers should discuss about it. But I guess tools like NWAM, Gnome power manager should like these. > so that > which authorizations/privileges should be assigned to the console > user? My initial idea is only consider the authorization. I'd like to see at least an temporary authorization will be assigned/removed from a console user when her log in/out. But maybe a role is more useful and flexible. I'm not sure of what privileges should be assigned, my personal idea is to assign the service management 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. Security team should also consider the issue, temporary auth/priviledge should not be flushed to /etc/user_attr. Think about the console_role_login -> assign temp auth -> flush to /etc/user_attr -> kernel panic. So what about the next time login? console_role_login will clean up all temp auth from all non-console users? > > 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 >
-- x82120 / +86 10 82618200
