Porting KAuthorized to KAuth for actions and resources

[Petr Mrazek]

Hello,
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 
and resources.
3. Port KioskTool to KDE4, revamping the interface and implementing the new 
needed features to make KAuth-based Kiosk configuration work smoothly for the 
system administrator
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.

The basics:
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 
found.

Anyway, I'd like to establish some clear set of requirements on what I should 
do here... maybe I'm overcomplicating it :)

Petr Mrázek