>The s6-svperms is a great feature but it only handle permissions control of a service at runtime. That means that we need to change the permissions of the service everytime that a reboot occurs.
>For a server, this is not really a big deal but for a desktop machine this can be really hard to handle as far as the runtime services can be different at each boot (user can activate or disactivate service for his purpose).
Right. The problem here is that the files holding the permissions all
exist in a tmpfs (typically they're all under /run), and are recreated
at every boot, with the default attributes.
If you run a supervision tree on a non-tmpfs, then the attributes will
be stored on disk, and kept from one boot to the next.
For a s6-linux-init + s6 + s6-rc installation, the service directories
are always on a tmpfs, so yes, the problem will manifest.
>Obviously, a script launched at some point of the boot (or after) can change the permissions on the necessary services. However, i think this is not easier and not flexible.
I disagree, I think it's the right way to address it; see below.
>S6-supervise create the control, status and event directory with the uid:gid of the owner of the process (correct me if i'm wrong).
That's correct - and the owner of the s6-supervise process is the owner
of the whole supervision tree.
>So, If we have a e.g <service>/data/perms/rules/uid/<uid>/allow file and if s6-supervise check this directory at the creation time and create the necessary file/directory with the respective uid/gid found at that directory, we can configure a service permissions permanently.
The problem with this approach is the following:
- The whole service directory is stored in RAM, so you cannot store
svperms attributes anywhere under the service directory - else you'll
have the exact same problem as you do now, the attributes will not
survive a reboot. :)
- s6-supervise does not and will not look at anything outside of a
service directory. The service directory is the place for everything
related to s6-supervise. (And even then, s6-supervise stays out of
data/ and env/.) So if you need configuration that cannot be stored
in a service directory because the service directory is all in tmpfs,
s6-supervise is not the program that can handle that configuration.
So, the best way to apply attributes to a set of service directories
is to have another process do it once the service directories have
been copied, because only an external process will be able to access
information that is stored on disk.
Typically, if you're using s6-rc, this can be done via a s6-rc
service running early, before the longruns are started. The "up"
script can read attributes from a file and set them; the "down"
script can save all the attributes to a file.
Ideally, though, the user would be able to declare the attributes
in service definition directories, and s6-rc would set them
automatically at start. That wouldn't help with early services, but
early services should be few and far between and their permissions
shouldn't be trifled with.
I can add that functionality to the next version of s6-rc. What do
you think?
--
Laurent
Received on Mon Feb 15 2021 - 11:58:59 UTC