These are good questions, and I haven't thought about all of them
thoroughly enough.
>* s6-rc-db: Changing the group of the 'lock' file in a compiled
>dababase and making it group writable allows the group's members to
>use the command. s6-rc-db cannot change the database or the service
>states, so are there any drawbacks to doing this? Is there a better
>way to use the command without being root?
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.
>* s6-rc: Changing the group of the 'lock' file in the live state
>directory, the group of the 'lock' file in the compiled dababase that
>is currently live, and making both group writable, allows the group's
>members to use, for example, the 's6-rc -a list' and 's6-rc -a
>listall' commands, but not the 's6-rc change' command, because
>permissions in other files and directories still prevent it. So are
>there any drawbacks to doing this? Is there a better way to use the
>command in forms that do not change service states without being root?
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. 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.
>* s6-svdt: Changing the group of the 'supervise' subdirectory of a
>service directory, and making it group readable, allows the group's
>members to use the command for the corresponding service.
>s6-svdt-clear still needs root privileges. So are there any drawbacks
>to doing this? Is there a better way to use the command without being
>root?
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.
>* s6-svstat: This is a tough one. Because the 'control' FIFO in the
>'supervise' subdirectory is only user-writable, this command can only
>be run as root. As far as I can tell, opening the FIFO is needed to
>check if the supervisor is running, and other daemontools-style
>supervision suites use a separate FIFO for this purpose, customarily
>named 'ok'. But changing the file's group and making it group writable
>also allows using s6-svc without being root. So is there a way to
>allow using s6-svstat, but not s6-svc, without being root?
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.
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.
>* Logging directories and kernel environment store: if they don't
>exist, s6-log creates logging directories with permissions 2700.
>s6-linux-init with the -s option creates the environment store with
>permissions 0700. Are there any drawbacks to changing their group to
>allow more users to read and search those directories?
No problem here, it's just data. s6-log and s6-l-i use paranoid
permissions by default because they don't know whether the information
they write is confidential, so the safer the better, but you're totally
free to change that to whatever you want.
--
Laurent
Received on Sun Feb 02 2020 - 20:14:44 UTC