Re: [systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?
Hello, Lennart Poettering [2016-04-04 21:28 +0200]: > We already bypass PK if the client is privileged. See > bus_verify_polkit_async() in src/shared/bus-util.c, the calls for > sd_bus_query_sender_privilege(). Are you saying that bypass doesn't > work for you? Right, it still calls Polkit as root normally. But if it's not really meant to do that, then let's just treat it as a bug and track it in https://github.com/systemd/systemd/issues/2748, I'll look into that. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?
On Mon, Apr 4, 2016 at 10:28 PM, Lennart Poettering wrote: > On Mon, 04.04.16 17:31, Martin Pitt (martin.p...@ubuntu.com) wrote: > > > Hello all, > > > > a recent (mostly cosmetical) bug report [1] made me aware that we > > currently query polkit for a lot of systemctl > > enable/daemon-reload/etc. calls from package maintainer scripts. At > > least in Debian, installing a package with a .service usually does > > something like "systemctl enable/start foo", and installing a package > > with a SysV script runs "systemctl daemon-reload" to pick up the new > > init script. > > > > In all those cases systemctl is guaranteed to run as root, and any > > potential interactive PK prompt would be totally unexpected -- because > > of root, and because package installation is supposed to be > > non-interactive and not hang. So this introduces a potentially > > unreliable moving part and also assumes that polkit actually works all > > the time (cf. package upgrades). > > We already bypass PK if the client is privileged. See > bus_verify_polkit_async() in src/shared/bus-util.c, the calls for > sd_bus_query_sender_privilege(). Are you saying that bypass doesn't > work for you? > Yes, apparently: https://github.com/systemd/systemd/issues/2748 -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?
On Mon, 04.04.16 13:06, Colin Walters (walt...@verbum.org) wrote: > > > On Mon, Apr 4, 2016, at 11:31 AM, Martin Pitt wrote: > > > A more upstreamable approach would be to not query polkit at all if > > geteuid() == 0. Is there any legit scenario where root would be denied > > running systemctl directly, but a polkit rule would allow it > > nevertheless? > > I can't think of one. However, see: > https://bugs.freedesktop.org/show_bug.cgi?id=35623 > > But that's okay, if kdbus happens I'm sure sd-bus/systemd > would be easy to change to teach it about CAP_SYS_ADMIN. > > The uid-vs-CAP_SYS_ADMIN is a lot more important in a > world of containers though. The code is actually written in a way that a specific capability is checked, depending on the method call is used. However this is only done if kdbus is used, since querying caps is not safely (i.e. non-racy) possible is kdbus is not available. On non-kdbus we simply check the euid == 0. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?
On Mon, 04.04.16 17:31, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello all, > > a recent (mostly cosmetical) bug report [1] made me aware that we > currently query polkit for a lot of systemctl > enable/daemon-reload/etc. calls from package maintainer scripts. At > least in Debian, installing a package with a .service usually does > something like "systemctl enable/start foo", and installing a package > with a SysV script runs "systemctl daemon-reload" to pick up the new > init script. > > In all those cases systemctl is guaranteed to run as root, and any > potential interactive PK prompt would be totally unexpected -- because > of root, and because package installation is supposed to be > non-interactive and not hang. So this introduces a potentially > unreliable moving part and also assumes that polkit actually works all > the time (cf. package upgrades). We already bypass PK if the client is privileged. See bus_verify_polkit_async() in src/shared/bus-util.c, the calls for sd_bus_query_sender_privilege(). Are you saying that bypass doesn't work for you? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd with an initramfs
Greetings, I am working on an embedded system where I load the users pace rootfs off of a loop device. I then use AUFS to put tmpfs overlay on it and then switch root into that. Currently systemd works like a champ getting through the initramfs. It correctly mounts the loop device, tmpfs and the aufs. I then also move the mounts for the loop filesystem and tmpfs into the /sysroot. This is where things start to have problems. While I can boot successfully into multi-user there is an error on boot about not being able to unmount the loop back mount. Jan 01 00:00:43 raspberrypi0 umount[215]: umount: can't umount /lib/live/rofs: Device or resource busy Of course it is busy because its hosting the userspace rootfs. Then further down I see these errors: Jan 01 00:00:43 raspberrypi0 systemd[1]: lib-live-rofs.mount: Unit is bound to inactive unit dev-loop0.device. Stopping, too. Jan 01 00:00:43 raspberrypi0 systemd[1]: lib-live-rofs.mount: Installed new job lib-live-rofs.mount/stop as 302 Jan 01 00:00:43 raspberrypi0 systemd[237]: lib-live-rofs.mount: Executing: /bin/umount /lib/live/rofs Jan 01 00:00:43 raspberrypi0 systemd[1]: Received SIGCHLD from PID 237 (umount). Jan 01 00:00:43 raspberrypi0 systemd[1]: lib-live-rofs.mount: Changed unmounting -> mounted Jan 01 00:00:43 raspberrypi0 systemd[1]: lib-live-rofs.mount: Installed new job lib-live-rofs.mount/stop as 303 Jan 01 00:00:44 raspberrypi0 systemd[1]: lib-live-rofs.mount: About to execute: /bin/umount /lib/live/rofs Jan 01 00:00:44 raspberrypi0 systemd[239]: lib-live-rofs.mount: Executing: /bin/umount /lib/live/rofs Jan 01 00:00:44 raspberrypi0 systemd[1]: lib-live-rofs.mount: Child 239 belongs to lib-live-rofs.mount Jan 01 00:00:44 raspberrypi0 systemd[1]: lib-live-rofs.mount: Trying to enqueue job lib-live-rofs.mount/stop/fail Jan 01 00:00:44 raspberrypi0 systemd[1]: lib-live-rofs.mount: Installed new job lib-live-rofs.mount/stop as 304 Jan 01 00:00:44 raspberrypi0 systemd[241]: lib-live-rofs.mount: Executing: /bin/umount /lib/live/rofs about 3x of this Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: About to execute: /bin/umount /lib/live/rofs Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Changed mounted -> unmounting Jan 01 00:00:46 raspberrypi0 systemd[1]: Unmounting /lib/live/rofs... Jan 01 00:00:46 raspberrypi0 systemd[258]: lib-live-rofs.mount: Executing: /bin/umount /lib/live/rofs Jan 01 00:00:46 raspberrypi0 systemd[1]: Received SIGCHLD from PID 258 (umount). Jan 01 00:00:46 raspberrypi0 systemd[1]: Child 258 (umount) died (code=exited, status=1/FAILURE) Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Child 258 belongs to lib-live-rofs.mount Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Mount process exited, code=exited status=1 Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Changed unmounting -> mounted Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Job lib-live-rofs.mount/stop finished, result=failed Jan 01 00:00:46 raspberrypi0 systemd[1]: Failed unmounting /lib/live/rofs. Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Unit is bound to inactive unit dev-loop0.device. Stopping, too. Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Trying to enqueue job lib-live-rofs.mount/stop/fail Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Installed new job lib-live-rofs.mount/stop as 312 Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Enqueued job lib-live-rofs.mount/stop as 312 Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: About to execute: /bin/umount /lib/live/rofs Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Forked /bin/umount as 260 Jan 01 00:00:46 raspberrypi0 systemd[1]: lib-live-rofs.mount: Changed mounted -> unmounting Jan 01 00:00:46 raspberrypi0 systemd[1]: Unmounting /lib/live/rofs... about 5x of this Jan 01 00:00:47 raspberrypi0 systemd[1]: lib-live-rofs.mount: About to execute: /bin/umount /lib/live/rofs Jan 01 00:00:47 raspberrypi0 systemd[1]: lib-live-rofs.mount: Forked /bin/umount as 270 Jan 01 00:00:47 raspberrypi0 systemd[1]: lib-live-rofs.mount: Changed mounted -> unmounting Jan 01 00:00:47 raspberrypi0 systemd[1]: Unmounting /lib/live/rofs... Jan 01 00:00:47 raspberrypi0 systemd[270]: lib-live-rofs.mount: Executing: /bin/umount /lib/live/rofs Jan 01 00:00:47 raspberrypi0 umount[253]: umount: can't umount /lib/live/rofs: Device or resource busy Jan 01 00:00:47 raspberrypi0 umount[255]: umount: can't umount /lib/live/rofs: Device or resource busy Jan 01 00:00:47 raspberrypi0 umount[258]: umount: can't umount /lib/live/rofs: Device or resource busy Jan 01 00:00:47 raspberrypi0 umount[260]: umount: can't umount /lib/live/rofs: Device or resource busy Jan 01 00:00:47 raspberrypi0 umount[262]: umount: can't umount /lib/live/rofs: Device or resource busy Jan 01 00:00:47 raspberrypi0 systemd-cgr
[systemd-devel] Any generic udev method for handling missing external programs?
Hi! I wondered if there already exists or were plans for some generic way to have an error on missing external programs that are invoked by udev rules. My particular problem was that somehow kpartx had gone missing on my system. 62-multipath-rules had a rule for invoking kpartx in order to make some linear devices to map to partition devices. It invoked these, and the call failed. This failure was logged in the journal, at level 3, which seems reasonable. However, there was no connection of the journal log entry with the multipath rule, or anything like that. The error was reported by the spawn_exec method, thus: """ Tue 2016-03-29 13:44:59.614256 EDT [s=07d0dd3e450e447b8176fae6f6ca2172;i=2759c4;b=4a123904d9fd4e2 7883b8169b32e4f8b;m=1b70a1aa78c;t=52f3396931d23;x=9bc01c815423a6b0] SYSLOG_FACILITY=3 _TRANSPORT=journal _UID=0 _GID=0 _CAP_EFFECTIVE=1f _BOOT_ID=4a123904d9fd4e27883b8169b32e4f8b _MACHINE_ID=c2a1a2c9555048fab5453a08361c43dc _HOSTNAME=megadeth.lab.bos.redhat.com PRIORITY=3 SYSLOG_IDENTIFIER=systemd-udevd _COMM=systemd-udevd CODE_FILE=src/udev/udev-event.c CODE_LINE=412 CODE_FUNCTION=spawn_exec ERRNO=2 MESSAGE=failed to execute '/sbin/kpartx' '/sbin/kpartx -a /dev/dm-25': No such file or directory _PID=40023 _SOURCE_REALTIME_TIMESTAMP=1459273499614256 """ The problem ramified, since the missing multipath partitions were part of another device, and so forth. It seems like it would be nice for the udev rules to be able to specify their external dependencies, and if their external dependencies were lacking, to stow a more useful message in the journal at some point. If this can't be checked until about to execute, then it would be nice if there was a somewhat more helpful message then the current one, which just says that the file is not found. If it can be checked when the rules are being processed, then udev could log the problem at that time. An argument could be made that no external programs that aren't certain to be installed should be called in the udev rules. kpartx is required by multipath, so in theory this rule would have ensured correctness. But, accidents do happen, like in this case where kpartx package was installed but kpartx executable had left the building. (Actually, kpartx package appears to be required by systemd so it would be reasonable to expect the executable to be around.) So, is it impossible, likely to happen soon, already done, not worth the trouble? TIA, - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?
On Mon, Apr 4, 2016, at 11:31 AM, Martin Pitt wrote: > A more upstreamable approach would be to not query polkit at all if > geteuid() == 0. Is there any legit scenario where root would be denied > running systemctl directly, but a polkit rule would allow it > nevertheless? I can't think of one. However, see: https://bugs.freedesktop.org/show_bug.cgi?id=35623 But that's okay, if kdbus happens I'm sure sd-bus/systemd would be easy to change to teach it about CAP_SYS_ADMIN. The uid-vs-CAP_SYS_ADMIN is a lot more important in a world of containers though. > In such a scenario, is it really legit to get an > interactive PK auth prompt for something like "systemctl enable foo" > when installing package foo? I think this would be good to cross-post to the polkit list, or at least if a choice is determined, summarize it there. But basically sounds fine to me to special case euid == 0, I think there is precedent elsewhere too. I thought NM did this, but I'm not seeing it in the code offhand. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?
Hello all, a recent (mostly cosmetical) bug report [1] made me aware that we currently query polkit for a lot of systemctl enable/daemon-reload/etc. calls from package maintainer scripts. At least in Debian, installing a package with a .service usually does something like "systemctl enable/start foo", and installing a package with a SysV script runs "systemctl daemon-reload" to pick up the new init script. In all those cases systemctl is guaranteed to run as root, and any potential interactive PK prompt would be totally unexpected -- because of root, and because package installation is supposed to be non-interactive and not hang. So this introduces a potentially unreliable moving part and also assumes that polkit actually works all the time (cf. package upgrades). My initial response was to propose some patches that all "systemctl" commands from maintainer scripts will be done with --no-ask-password. However, this would require rebuilding a lot of packages, and I would guess this affects other distribuions in some way too? A more upstreamable approach would be to not query polkit at all if geteuid() == 0. Is there any legit scenario where root would be denied running systemctl directly, but a polkit rule would allow it nevertheless? In such a scenario, is it really legit to get an interactive PK auth prompt for something like "systemctl enable foo" when installing package foo? Thanks for opinions, Martin [1] https://launchpad.net/bugs/1565617 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
