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