On Monday 08 October 2007 22:11:31 Justin Haygood wrote:
(For some background on PolicyKit, http://people.freedesktop.org/~david/polkit-spec.html is a good read).
Indeed a good read. I need to learn more about the design of actions and their restrictions. Sadly, the documentation is really bad (except for that link you posted)
Basically.. here's an idea for openSUSE 11+. Make YaST use PolicyKit to determine if it does certain actions or not. This would grant the following:
I followed the tutorial and seems nice. I have some questions anyway. From what I understood we would need: - Find most "actions" in YaST (we could start with something as smple as "apply" changes in some modules, and declare them to policykit - Create some YaST level wrapper of libpolkit so YCP modules could talk to PolicyKit just before doing some action. The problem is, the second part requires the action to be in a separate process, and this is not that "easy" to extract from YaST. When we start using someday things like CIM providers, then it is really easy, each method is a kind of action. and some process embedding the CIM server is enough.
1. YaST (at least Qt and GTK+) itself will run as the user. This would allow for many benefits, i.e., GUI code isn't run privileged, etc.. 2. The system administrator could allow certain modules to be run without a root password.
Yes, the benefits are clear.
3. The actual programs doing the actions would be forced to be separated from the UI code (a good design anyway), with something like the system message bus (D-Bus) as the middle man.
We already have separation of Modules (APIs) and clients (workflows). What can else you can separate? - UI descriptions. Which only work if your widgets are not dynamic. Otherwise you can extract the base, and attach the behavior in the controller, plus any widget change. - The controller. At least the 2 parts above are already separated from modules in YaST, so we could say, modules and their APIs are the "mechanisms", but the modules API is not that straightforward to extract as actions.
AppArmor can even be utilized by making the privileged helper programs that do the actual work only able to do what they are intended to be done. The split between the privileged helpers and the unprivileged UI can probably be made easier by some easy APIs integrated into YCP, etc..
Yes
I plan on learning on how to make YaST modules by writing a "System Policy Editor" which will manage PolicyKit policies. It seems to be a self-documenting XML format, that the policy editor can then parse and use to provide a nice easy to use policy editor.
Nice idea. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org