Mailinglist Archive: yast-devel (132 mails)

< Previous Next >
Re: [yast-devel] YaST / PolicyKit integration
  • From: Marcus Meissner <meissner@xxxxxxx>
  • Date: Wed, 10 Oct 2007 15:32:38 +0200
  • Message-id: <20071010133238.GD25918@xxxxxxx>
On Wed, Oct 10, 2007 at 09:26:24AM -0400, Justin Haygood wrote:
> 
> On Wed, 2007-10-10 at 15:19 +0200, Marcus Meissner wrote:
> > On Mon, Oct 08, 2007 at 04:11:31PM -0400, Justin Haygood wrote:
> > > (For some background on PolicyKit,
> > > http://people.freedesktop.org/~david/polkit-spec.html is a good read).
> > > 
> > > 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:
> > > 
> > > 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.
> > > 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.
> > 
> > They should be very strictly seperated and only offer choices a
> > user really should be able to do.
> > 
> > There is always the very inherent danger of giving the user root-equivalent
> > access, like we did with the package management stack in 10.1/SLE10.
> > 
> > This should not be possible of course.
> > 
> > Ciao, Marcus
> 
> The biggest thing about PolicyKit is that the exact abilities of the
> user is configurable by the system administrator on an action by action
> basis. I'm actually starting work on a YaST module to edit PolicyKit
> policies (a few of these already exist for HAL actually).
> 
> For instance, of admin wants to allow user X to administer the HTTP
> server using YaST, but doesn't want to give user X the root password, he
> can configure the action(s) for administrating the HTTP server to be
> able to use user X's own password for authorizing user X to perform the
> action.

True.

Additionaly...
I think to abstract actions where a user can more or less directly gain
root access using such services is a wasted effort.
For those cases just give him full sudo rights and be done.

Ciao, Marcus
-- 
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups