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 :)
The instructions are these:
1. Investigate on Kiosk and KAuth and elaborate a coding plan on how to
approach the issue.
2. Port KAuthorized to KAuth (kdelibs/kdecore/kernel/kauthorized) for actions
3. Port KioskTool to KDE4, revamping the interface and implementing the new
needed features to make KAuth-based Kiosk configuration work smoothly for the
4. Create a small tool to migrate old Kiosk settings to the new framework
(could be integrated into KioskTool)
5. Create some small tests to prove the functionalities of the new method.
6. Prepare the code for being merged into KDELibs.
I have a pretty good understaning of the workings of KAuthorized, because it's
not complicated at all. It's a thin wrapper on top of KConfig with a bit of
pattern matching for URLs thrown in.
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. Grep
should handle that, but asking is simpler :)
KAuth *seems* to be pretty straightforward.
Correct me if I'm wrong :)
Now some problems I've encountered:
The Kiosk user/group profiles (stored in /etc/kde-profile/ on my system):
There simply is no equivalent to them in KAuth AFAIK. This is a problem,
because when I say in KioskTool that profile P should be applied to user U,
U's configuration files aren't affected. With KAuth being used for storing
this configuration stuff, I'd be changing the user's configuration directly.
A tool that would convert profiles from Kiosk into something that KAuth could
use seems... complicated. Either KAuth would have to have support for these
profiles (an API focused on access to the underlying functionality, providing
support for per-user and per-group profiles) or I'll have to change the
semantics for only a part of Kiosk.
This would be confusing to the user (one part using KConfig and its immutable
settings in a text file, another using KAuth, which is a wrapper around
something completely different)
Now if I applied such a profile to some user and then applied a different
profile, I'd have to first remove the changes the first profile did. Throw in
some changes done manually, and you have a recipe for something really ugly.
Each 'component' (application, kpart) can have the groups used by KAuthorized
in its rc file. To KAuthorized, these are basically indistinguishable from
those in the Kiosk profiles. So now we have user profiles, group profiles, the
global KDE config file and applicatication rc files, all combined into one
neat/messy package, with 'immutable' thrown in. If I have to convert this to
something meaningful, I'll have to somehow probe all the KConfig configuration
objects outside of KConfig, in the same way KConfig does this. Looks like a
hack to me ~_~
This extends to KAuth, which expects the actions to be specified in a .actions
file(s). The same action could (almost certainly will) exist in multiple
different 'namespaces' for the applications, user, group, etc.
Applications can easily just ignore KAuthorized and use KConfig directly.
In general, I'm trying to make two APIs intended for querying some databases
without modifying anything to talk to each other. I could hack in something
that would avoid them completely and work from 'outside', but that looks
really wrong to me.
I could treat KAuth as an alternative storage for those settings and check for
them in KAuthorized first, combined with a simple hand-made .actions file for
all the supported actions/resources. That seems be a bit too simple to me. I
might end up doing this if I can't find some good solutions for the problems I
Anyway, I'd like to establish some clear set of requirements on what I should
do here... maybe I'm overcomplicating it :)