Porting KAuthorized to KAuth for actions and resources
drf54321 at gmail.com
Sun Mar 21 18:40:51 GMT 2010
On Sunday 21 March 2010 11:45:29 Oswald Buddenhagen wrote:
> 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. :)
> > 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
> 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
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
> - 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 ...
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel