PolicyKit + KDE

Dario Freddi drf54321 at gmail.com
Wed Sep 2 17:55:47 BST 2009


Hi all,

just before people start screaming at random brokeness, let's make some 
clarifications. Let's start with some points we all should agree with 
(hopefully)

 - Software that do not belong to system space should be installable in 
userspace
 - Software in userspace should not even attempt to perform root operations
 - KDE can be built without kauth => polkit, having, by result, all root 
actions denied, so it correctly fits with previous statements

Now, that said, I still do not understand where is the problem with polkit. If 
you are installing stuff userspace, you should be aware of its limitations. 
Not having Kauth does _NOT_ compromise your environment, it just locks you out 
from privileged operations, which is quite bearable.

I already fixed cmake (more or less, still have to test throughly) to make 
stuff install outside /usr and /etc, and I will also make it spit a warning on 
install if these files are installed outside, so people who really care about 
having things privileged working can simply issue a sudo mv.

Also, saying that a software is broken just because it does not allow you to 
include config files from elsewhere just seems to me unrespectful towards his 
developer, no matter if it's a *Kit or GNOME stuff, especially because there 
are possible good reasons for doing that.

Ah, for the records, we just found out that changing the include path for dbus 
policy/autostart files seems not to work on most installations. So are we 
going to call DBus broken and move it outside of KDE? I think it won't happen.

PolicyKit is decent software (even if 0.x is not really nice API-wise), and 
it's improving, no matter where it comes from. It's not perfect, but it works 
and it's the only solution we have out there (thanks god, I don't want a mass 
of clones coming out), it is maintained, sponsored and it has a future. Also 
people from Red Hat are helping a lot in the transition to polkit-1.

That said, I hope you realized that these 3 file won't make your pc explode if 
they are not installed in the right location but will just prevent you using 
systemsettings to change the system date/time and from killing privileged 
processes with KSysGuard, hence will not prevent you from developing and 
rocking on KDE as usual.

Hoping that this could put an end to the random hate.

In data mercoledì 02 settembre 2009 00:03:47, John Tapsell ha scritto:
: > Hi all,
>
>   The problem is "make install" in kdelibs/kdebase  has traditionally
> only installed files to your $KDEDIR directory.  However with
> policykit requires files to be installed elsewhere.  For example
> ksysguard now needs to install to:
>
> /etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
> /usr/share/dbus-1/system-services/org.kde.ksysguard.processlisthelper.servi
>ce /usr/share/PolicyKit/policy/org.kde.ksysguard.processlisthelper.policy
>
> To do so requires root privillages and modifies the main system - no
> longer giving us the possibility of playing with one version of kde
> which having another installed.
>
> I can't really see any good solution.  At minimum we could modify the
> build files so that it doesn't fail if you run make install as a
> normal user, although this means that any app requiring root rights
> would fail with authorization errors.  Perhaps this is sufficiently
> good.
>
> This would also prevent policy kit from working if KDE is on a network
> share - a common setup in universities.  I don't know how much of a
> problem this would be.
>
> JohnFlux

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- 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/20090902/b31f066f/attachment.sig>


More information about the kde-core-devel mailing list