Plans for revamping Kiosk and KAuthorized

[Dario Freddi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090923/3ee6bb41/attachment.sig>