Birger Kollstrand wrote:

Great news!

I hope package installation by non root users are under consideration?

Yes, whole Yast should support role based access in the future, this is just the first step.

If so, can that be made on a rules basis so that ie. my daughter can update the packages already installed but not add new? Or add packages from one pattern but not others?

Yes, update only role is one of the use cases we would like to support. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Vincent Untz wrote: [...]

Is the second step to use a dbus service ("You have to enable PolicyKit actions performed by a particular Yast module to the relevant users.") a temporary one or will it stay this way?

I'd like to enhance policy checks for generic agents. The problem is that some agents are generic (like .target.bash or .process) and the current policy checks on the common SCR level are not sufficient for them. (The check is performed before calling an SCR agent.) For example .target.bash agent is a generic agent for starting _any_ shell command as root. For security reasons the command is now part of the policy ID but due to the PolicyKit limitations the mapping is not one to one. PolicyKit permits only [0-9], [a-z] and _. (underscore and dot) characters only, yast replaces all invalid characters by underscore. The problem is that potentially the user could call the agent with different command which encodes to the same policy ID. Imagine hypothetic /bin/Date binary for setting the system time (in addition to the usual /bin/date which reads time). If an user is allowed to do org.opensuse.yast.scr.execute.target.bash-output-bin-date action (which allows to execute /bin/date) he is also allowed to execute /bin/Date which should be forbidden. Another problem is the the policy ID cannot be longer than 255 characters. So "/bin/myprogram --option1 .... -option200" and "/bin/myprogram --option1 .... --option200 -option201" might be truncated to same ID which means that the user could add extra options which might completely change the meaning of the command. The solution is that there should be a mapping file which would map "complete SCR command" to "unique actionID". Example: SCR::Execute + .target.bash_output + "/bin/date" -> org.opensuse.yast.scr.action.readtime. The result is that you will need to change some policies in the future (if the yast module uses a generic agent). I'll open a bug for that, this a security problem which must be solved in 11.1. Another required change will be needed when we introduce DBus/PolicyKit in the logic layer later. But this will be done probably after 11.1. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org