Mailinglist Archive: yast-devel (132 mails)

< Previous Next >
Re: [yast-devel] YaST / PolicyKit integration
  • From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
  • Date: Tue, 9 Oct 2007 11:18:53 +0200
  • Message-id: <200710091118.54056.dmacvicar@xxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
References