Plans for revamping Kiosk and KAuthorized

Aaron J. Seigo aseigo at kde.org
Wed Sep 23 19:37:24 BST 2009


On September 23, 2009, Oswald Buddenhagen wrote:
> On Wed, Sep 23, 2009 at 12:03:07PM +0200, Dario Freddi wrote:
> > *1. Revamp KAuthorized by using KAuth as the backend*
> > At the moment Kiosk is based upon some KConfig files.
> >
> > This is not so great when it comes to security and flexibility,
> 
> please explain.
> 
> by changing the backend you make all existing configurations
> ineffective. a tool to migrate configs should be written.

yes, we absolutely _must_ have a migration strategy that maps the existing 
system to the new mechanisms with 100% fidelity. 

the suggestion made at Tokamak was to have KAuthorized check both 
KGlobal::config() (which should be cheap) and fall back to KAuth. we would 
then deprecate the KGlobal::config() based authorizations and remove support 
for them in KDE 5. KAuth could even provide the KGlobal::config() 
compatibility backend internally for these specific kinds of authorization 
requests and KAuthorized would become a convenience API over that.

> kconfig's isImmutable() may be/is used to lock down configuration
> dialogs, etc. 

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]

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

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090923/689fbf11/attachment.sig>


More information about the kde-core-devel mailing list