El dom., 2 feb. 2020 a las 17:14, Laurent Bercot escribió: > > >* s6-rc-db: [...] > There shouldn't be any drawbacks. Honestly, the lock file in a > database is only necessary because of s6-rc-bundle, which is the only > program that can modify a compiled db at the same time it is being read; > the intent is not for it to be a roadblock for anything. So, change its > group to your heart's content; I should add an option to s6-rc-compile > to do that at db creation time.
OK. An option would save an extra chgrp + chmod step. s6-rc-bundle still fails, as expected: $ s6-rc-db -c db list all a-oneshot a-longrun s6rc-fdholder s6rc-oneshot-runner $ s6-rc-bundle -c db add a-bundle a-longrun s6-rc-bundle: fatal: unable to open db/resolve.cdb.new: Permission denied > >* s6-rc: [...] > This is a bit more borderline, because a user can still run > "s6-rc change" and it will attempt to change the machine state, and will > probably yield a big batch of errors about s6-svc being forbidden to > change a service state or s6-sudoc being unable to connect to the > oneshot runner. Things should work exactly as they're supposed to, but > it might be pretty ugly. Yeah, it all works as expected; YMMV about the clarity of error messages. $ s6-rc -ul live change a-longrun s6-rc: fatal: unable to take locks: Permission denied [After chgrp + chmod, and starting s6rc-oneshot-runner] $ s6-rc -dl live list s6rc-oneshot-runner s6rc-fdholder a-longrun a-oneshot $ s6-rc -ul live change a-oneshot s6-sudoc: fatal: unable to connect to the s6-sudod server - check that you have appropriate permissions s6-rc: warning: unable to start service a-oneshot: command exited 111 $ s6-rc -ul live change a-longrun s6-svlisten1: fatal: unable to subscribe to events for live/servicedirs/a-longrun: Permission denied s6-rc: warning: unable to start service a-longrun: command exited 111 s6-svc: fatal: unable to control live/servicedirs/a-longrun: Permission denied [OK, make the 'event' fifodir publicly accessible and try again] $ s6-rc -ul live change a-longrun s6-svlisten1: fatal: unable to s6_svstatus_read: Permission denied s6-rc: warning: unable to start service a-longrun: command exited 111 s6-svc: fatal: unable to control live/servicedirs/a-longrun: Permission denied [OK, make 'supervise' group searchable and try again, see later] $ s6-rc -ul live -t 1000 change a-longrun s6-svc: fatal: unable to control live/servicedirs/a-longrun: Permission denied s6-svlisten1: fatal: timed out s6-rc: fatal: timed out > If you don't mind ugliness, fine; but if you > want me to make it official, I'll want to add a permissions check to > "s6-rc change" in order to fail early and cleanly. Personally, I don't mind the messages. I am able to interpret them, and there is a "permission denied" there anyway, but then again, I am familiar with some of s6-rc's internals. I don't know about other people, though. > >* s6-svdt: [...] > I haven't studied this in detail, but making the permissions of a > supervise/ directory distinct from those of the whole supervision tree > sounds sketchy to me. If you make supervise/ readable by another group, > it means permissions of the files inside need to be carefully crafted, > which I'm not sure is the case for everything. At the very least the > status file should be made unreadable by others - not that it's > critical, > but restricting certain stuff to a group is pretty meaningless if other > stuff such as the state of the service is available to everyone. After further testing, it turns out that being group *searchable* (permissions 0710) is enough for unprivileged use. It seems that the openat() call that s6-svdt makes to read the death tally (and also s6-svlisten1 for the status file) fails otherwise. $ s6-svdt scan/a-longrun s6-svdt: fatal: unable to read death tally for service scan/a-longrun: Permission denied strace reveals that, for s6-svlisten1: openat(AT_FDCWD, "scan/a-longrun/supervise/status", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied) And for s6-svdt: openat(AT_FDCWD, "scan/a-longrun/supervise/death_tally", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied) > >* s6-svstat: [...] > > That's an excellent finding! > I always thought daemontools (from which every other suite takes > inspiration!) had a separate 'ok' fifo because using the 'control' fifo > as a usage marker involves some tricky manipulation at supervisor start, > and djb just couldn't be bothered. I got rid of 'ok' because that saves > one fd. But you're right: separating 'ok' from 'control' allows checking > whether the supervisor is running with a different permission set from > actually sending commands. To be honest, after seeing that daemontools supervise's code opened the 'ok' FIFO for reading and did nothing else with it other that marking the corresponding file descriptor close-on-exec, for the longest time I wondered why it even existed. But looking at daemontools svstat's code, yes, that is the FIFO that is checked to print the "supervise not running" message. Nothing is done with the ´control' FIFO. > Do you think it's worth it to change the locking implementation back > to one that uses an additional fd in order to make s6-svstat more > accessible? Keep in mind s6-supervise is long-running and there can be > *a lot* of them on a system, so it might add up to hundreds of extra > open descriptors. I'm unsure. I think that from a UX (haha) perspective, not being able to use s6-svstat, and s6-svdt to a lesser degree, as an unprivileged user might feel too restrictive, and, with a single FIFO setup, that doesn't look possible without also allowing unprivileged use of s6-svc. Also, people who currently use runit have those hundreds of open descriptors already. Thanks, G.
