Porting KAuthorized to KAuth for actions and resources

[Dario Freddi]

On Sunday 21 March 2010 11:45:29 Oswald Buddenhagen wrote:
> hi,
> 
> On Sat, Mar 20, 2010 at 09:57:57PM +0100, Petr Mrazek wrote:
> > I've picked this for my bachelor's thesis and I'd like to discuss some
> > of the specifics, ask some questions and point out some problems I
> > found :)
> 
> you seem to have done a pretty thorough job so far. :)

+1

> 
> > Kiosk/KConfig appears to be a tougher thing to crack. I'd like to know
> > where and how exactly are the Kiosk user/group profiles loaded by
> > KConfig.
> 
> there really isn't much to it. it all works magically by virtue of
> kconfig's cascading. kdelibs/kdecore/config/ => kconfigdata.h and
> kconfigini.cpp.
> 
> 
> as you noted, there are two basic concepts in kiosk.
> 
> the one are explicit action restrictions, i.e., KAuthorized. this
> concept maps pretty well to KAuth, so it should be rather
> straight-forward to implement it and migrate the data. how the cascading
> (i.e., merging of group and user policies) is done should be probably
> left to the discretion of the KAuth backends, but dario will know
> better.

Basically each KAuth action has (especially in the linux case) an implicit and 
explicit policy: the implicit policy defines the "default" policy for the 
action, whereas the explicit one is a fine-tuning that associates a specific 
policy to a group of users/groups.

What's the problem in this: KAuth does not (yet) provide an api to change the 
implicit/explicit policies, so migrating the existing policies is quite hard.

What I would like to see/do/have done is the following: abstracting the 
policies editing in a part of KAuth, and have, instead of the polkit KCM that 
I'm redesigning for the second time and I sure won't do for the third, a 
"KAuth policy editing" tool, which might as well go hand in hand with the new 
KioskTool as a centralized point to edit system's policies.

This would solve, as you might imagine, more than one problem.

> 
> the second concept are configuration lockdowns. applications may ask
> kconfig whether they have write access to particular settings and adjust
> their ui accordingly. in theory, it would be possible to store the
> immutability flags in KAuth as well. however, this comes with some
> downsides:
> - querying writability for keys/groups/files currently comes virtually
>   for free, while with the change it would require a roundtrip to kauth
>   each time. i.e., it would be a resource hog.
> - the entire idea is counter-productive from an administrative point of
>   view: before locking down a configuration, it has to be made in the
>   first place, which happens in the config files anyway, usually with a
>   text editor. detaching the immutability flags from the actual
>   configuration would require creating and maintaining a "shadow
>   structure", which is just additional effort and risk of inconsistency.
> consequently i'd argue that the backend implementation of this aspect of
> kiosk should not be changed.

I'm fully with Oswald here.

> on the ui side, you may want to finish off
> and integrate playground/utils/kconfigeditor/ somehow. maybe lukas has
> something to say about that.

Again, it would be nice to merge kconfigeditor - kiosktool - polkit kcm into a 
"one tool for rule them all".

> 
> so far my thoughts ...

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

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/20100321/11ca3cf9/attachment.sig>