[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Plans for revamping Kiosk and KAuthorized
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2009-09-23 19:11:20
Message-ID: 200909232111.24393.drf54321 () gmail ! com
[Download RAW message or body]


On Wednesday 23 September 2009 20:37:24 Aaron J. Seigo wrote:> 
> let's not make things more confusing than necessary here. Dario is talking
> about action, control panel and URL authorizations here. locking down user
> data is not relevant to this discussion.
> 
> what is relevant are these groups in config files:
> 
> [KDE Resource Restrictions]
> [KDE Action Restrictions]

Yes, and we should probably start by doing this. I'll document myself further 
(thanks David :) ) and integrating some of the things you already said here, 
and be back with a small pdf with the detailed plan on the list as soon as 
possible (allow me 1-2 weeks) to have a precise and concrete design pattern. I 
can't guarantee we'll have the complete system ready by 4.4 (also because I 
want kiosktool to be 100% in parity with its current status before pushing any 
change to KAuthorized), but for 4.5 is surely a reasonable target

> 
> >  you can then either live with two ways to do very similar
> > things, or you cover that part as well
> 
> there already are two ways to do very similar things. one way to control
>  the following:
> 
> * "this user may change the settings in the control panel which requires
> elevated privileges"
> 
> * "this user may install/remove software"
> 
> * "this user may perform <insert system behaviour modification>"
> 
> these days the above is accomplished via something like policykit. KDE does
> not provide an additional mechanism for them as they are usually lower in
>  the system than our code reaches.
> 
> there is another way to control the following:
> 
> * which URLs KDE applications may access
> 
> * which actions may show up in XMLGUI based applications
> 
> * which categories of special actions in KDE applications are allowed (e.g.
> root commands; running .desktop files in the home dir)
> 
> these are done using KDE's Kiosk framework.
> 
> so, from a sysadmin POV, we have two ways of doing things right now. KAuth
> aims to offer _one_ way to do them: the system's provided authorization
>  system (e.g. policykit on Linux).
> 
> the change in our thinking in Kiosk is to separate out system interaction
> issues from application configuration settings.
> 

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]