Porting KAuthorized to KAuth for actions and resources

Oswald Buddenhagen ossi at kde.org
Sun Mar 21 10:45:29 GMT 2010


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. :)

> 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.

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. on the ui side, you may want to finish off
and integrate playground/utils/kconfigeditor/ somehow. maybe lukas has
something to say about that.

so far my thoughts ...





More information about the kde-core-devel mailing list