Rick Moen <rick@linuxmafia.com> writes:
e.g., routing all process privilege decisions through PolKit
I have systemd v215 on Debian 8 working, without policykit-1. libpolkit* are installed, but AFAIK that's "mostly harmless".
From the manpages, it looks like you can do e.g.
hostnamectl -P foo instead of pkexec hostnamectl foo sudo hostnamectl foo su -c 'hostnamectl foo' But if you're already root, it doesn't matter. In fact, on Debian 8 the -P option is in the manpage, but it appears to be compiled out by a ./configure choice: root@het:~# hostnamectl --help |& grep privileged root@het:~# hostnamectl --privileged status hostnamectl: unrecognized option '--privileged' This is no worse than the crazy shit where systemctl runs SSH for you: systemctl -H example.net restart ssh.service becomes ssh example.net systemctl restart ssh.service Likewise systemctl --root=/target disable dev-mqueue.mount is almost but not quite the same as chroot /target systemctl disable dev-mqueue.mount The only other reference to polkit I can find is in systemd-logind, which seems to be saying If fred says "shutdown the system", I'll ask polkit if fred is allowed to do that. Having said that, my experience with recent GNOME & XFCE code is that when they need escalated privileges (e.g. to umount /media/Porn\x20USB\x20Key), the only mechanism they choose to implement is polkit. i.e. you can't tell them Dude, don't bother sending an umount XML-IPC request to the polkit dbus service, just run "sudo umount". TRUST ME, it'll work. AFAICT the reason for this is that password prompting without a tty was really ugly in gksudo and polkit is... less ugly. >SHRUG<
Anyway, with reasonable luck, it'll have about as long an ascendency as HALd and devfsd, as it's certainly about as popular.
Last time I looked, I got the strong impression that upower & udisks codebases were *literally* just copy-and-pasted from hal codebase, i.e. badge engineering. (Apart from the bits that merged into udev, that is.)