Plans for revamping Kiosk and KAuthorized

[Gary Greene]

On 9/23/09 12:11 PM, "Dario Freddi" <drf54321 at gmail.com> wrote:
> On Wednesday 23 September 2009 20:37:24 Aaron J. Seigo wrote:>
>> let's not make things more confusing than necessary here. Dario is talking
>> about action, control panel and URL authorizations here. locking down user
>> data is not relevant to this discussion.
>> 
>> what is relevant are these groups in config files:
>> 
>> [KDE Resource Restrictions]
>> [KDE Action Restrictions]
> 
> Yes, and we should probably start by doing this. I'll document myself further
> (thanks David :) ) and integrating some of the things you already said here,
> and be back with a small pdf with the detailed plan on the list as soon as
> possible (allow me 1-2 weeks) to have a precise and concrete design pattern. I
> can't guarantee we'll have the complete system ready by 4.4 (also because I
> want kiosktool to be 100% in parity with its current status before pushing any
> change to KAuthorized), but for 4.5 is surely a reasonable target
> 
>> 
>>>  you can then either live with two ways to do very similar
>>> things, or you cover that part as well
>> 
>> there already are two ways to do very similar things. one way to control
>>  the following:
>> 
>> * "this user may change the settings in the control panel which requires
>> elevated privileges"
>> 
>> * "this user may install/remove software"
>> 
>> * "this user may perform <insert system behaviour modification>"
>> 
>> these days the above is accomplished via something like policykit. KDE does
>> not provide an additional mechanism for them as they are usually lower in
>>  the system than our code reaches.
>> 
>> there is another way to control the following:
>> 
>> * which URLs KDE applications may access
>> 
>> * which actions may show up in XMLGUI based applications
>> 
>> * which categories of special actions in KDE applications are allowed (e.g.
>> root commands; running .desktop files in the home dir)
>> 
>> these are done using KDE's Kiosk framework.
>> 
>> so, from a sysadmin POV, we have two ways of doing things right now. KAuth
>> aims to offer _one_ way to do them: the system's provided authorization
>>  system (e.g. policykit on Linux).
>> 
>> the change in our thinking in Kiosk is to separate out system interaction
>> issues from application configuration settings.
>> 

Another thing to note about the kiosk framework is that it also allowed
administrators to "tailor" the profile as well so you could hide not just
the various actions, but also the menu, etc. There are a number of things
that kiosktool does that are far off from the authorization of actions.

-- 
Gary L. Greene, Jr.
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.