supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* [announce] skalibs-2.10.0.1, execline-2.7.0.1, s6-2.10.0.1
@ 2021-01-25 16:50 Laurent Bercot
  2021-01-26  3:11 ` Alexis
  2021-02-15  2:37 ` [s6-svperms] Handling service permissions at creation time eric vidal
  0 siblings, 2 replies; 6+ messages in thread
From: Laurent Bercot @ 2021-01-25 16:50 UTC (permalink / raw)
  To: skaware, supervision


  Hello,

  New skarnet.org packages are available:

  skalibs-2.10.0.1
  execline-2.7.0.1
  s6-2.10.0.1

  Those are bugfix releases.
  I normally don't announce bugfix releases, but the bugs that have
been fixed here are pretty visible (sorry about that!), so all users
are encouraged to upgrade ASAP.

  https://skarnet.org/software/skalibs/
  https://skarnet.org/software/execline/
  https://skarnet.org/software/s6/

  Enjoy,
  More bug-reports always welcome.

--
  Laurent


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [announce] skalibs-2.10.0.1, execline-2.7.0.1, s6-2.10.0.1
  2021-01-25 16:50 [announce] skalibs-2.10.0.1, execline-2.7.0.1, s6-2.10.0.1 Laurent Bercot
@ 2021-01-26  3:11 ` Alexis
  2021-02-15  2:37 ` [s6-svperms] Handling service permissions at creation time eric vidal
  1 sibling, 0 replies; 6+ messages in thread
From: Alexis @ 2021-01-26  3:11 UTC (permalink / raw)
  To: skaware, supervision


Laurent Bercot <ska-skaware@skarnet.org> writes:

>  New skarnet.org packages are available:
>
>  skalibs-2.10.0.1
>  execline-2.7.0.1
>  s6-2.10.0.1

And i've just updated the s6-man-pages repo accordingly:

https://github.com/flexibeast/s6-man-pages/releases/tag/v2.10.0.1.1


Alexis.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [s6-svperms] Handling service permissions at creation time.
  2021-01-25 16:50 [announce] skalibs-2.10.0.1, execline-2.7.0.1, s6-2.10.0.1 Laurent Bercot
  2021-01-26  3:11 ` Alexis
@ 2021-02-15  2:37 ` eric vidal
  2021-02-15 11:58   ` Laurent Bercot
  1 sibling, 1 reply; 6+ messages in thread
From: eric vidal @ 2021-02-15  2:37 UTC (permalink / raw)
  To: supervision

Hi there,

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).

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 thought about a practical solution. 

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).
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.
 
What's your thought about that?

-- 
eric vidal <eric@obarun.org>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [s6-svperms] Handling service permissions at creation time.
  2021-02-15  2:37 ` [s6-svperms] Handling service permissions at creation time eric vidal
@ 2021-02-15 11:58   ` Laurent Bercot
  2021-02-15 12:21     ` Colin Booth
  0 siblings, 1 reply; 6+ messages in thread
From: Laurent Bercot @ 2021-02-15 11:58 UTC (permalink / raw)
  To: eric vidal, supervision

>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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [s6-svperms] Handling service permissions at creation time.
  2021-02-15 11:58   ` Laurent Bercot
@ 2021-02-15 12:21     ` Colin Booth
  2021-02-15 14:56       ` Laurent Bercot
  0 siblings, 1 reply; 6+ messages in thread
From: Colin Booth @ 2021-02-15 12:21 UTC (permalink / raw)
  To: supervision

On Mon, Feb 15, 2021 at 11:58:59AM +0000, Laurent Bercot wrote:
> > 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.
> 
>  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?
> 
Services can fix their own permissions so if s6-rc is going to grow that
functionality it should be in the generated run, not in some rarely used
outboard helper service.
-- 
Colin Booth

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [s6-svperms] Handling service permissions at creation time.
  2021-02-15 12:21     ` Colin Booth
@ 2021-02-15 14:56       ` Laurent Bercot
  0 siblings, 0 replies; 6+ messages in thread
From: Laurent Bercot @ 2021-02-15 14:56 UTC (permalink / raw)
  To: Colin Booth, supervision

>Services can fix their own permissions so if s6-rc is going to grow that
>functionality it should be in the generated run, not in some rarely used
>outboard helper service.

  As answered on IRC, for ML completeness: no, because permissions should
be fixed when the supervisor starts, not when the service starts. So a
oneshot that runs right after the supervisors are started is the
correct solution.

--
  Laurent


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-02-15 14:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-25 16:50 [announce] skalibs-2.10.0.1, execline-2.7.0.1, s6-2.10.0.1 Laurent Bercot
2021-01-26  3:11 ` Alexis
2021-02-15  2:37 ` [s6-svperms] Handling service permissions at creation time eric vidal
2021-02-15 11:58   ` Laurent Bercot
2021-02-15 12:21     ` Colin Booth
2021-02-15 14:56       ` Laurent Bercot

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/supervision

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 supervision supervision/ http://inbox.vuxu.org/supervision \
		subscribe@list.skarnet.org
	public-inbox-index supervision

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.supervision.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git