S6-SVPERMS(8)

📦 version 2.15.1.0, in nixpkgs unstable

🌸 s6-svperms(8) — the group-chat guide to service perms 💅

okay so bestie, this is a page from the System Manager's Manual, and it's about s6-svperms — the little tool that lets you peek at, or change, the permissions on a bunch of services. Specifically: who can read their states, who can send them control commands, and who can subscribe to their up/down events. 👑

✨ SYNOPSIS ✨

s6-svperms [-v] [-u | -g group | -G group | -o | -O group]
           [-e | -E group] servicedirs...

🎀 DESCRIPTION 🎀

the "just looking" mode 👀

So like, with no options, or with only the -v option, s6-svperms prints 3 lines to stdout for every service directory you listed in servicedirs. Each line has the name of the service directory first, then the tea on one of these three things:

  • status: — who's allowed to read status info about the service, using stuff like s6-svstat(8) or s6-svdt(8). The values can be:
    • owner — literally just the owner of the service 🫶
    • group:name — the owner and the members of group name
    • public — everybody, all users, the whole timeline 🌈
  • control: — who's allowed to send control commands to the service, with things like s6-svc(8). The values can be:
    • owner — just the owner of the service
    • group:name — the owner and members of group name
  • events: — who's allowed to subscribe to events that s6-supervise(8) sends for this service, using things like s6-svwait(8) or s6-svlisten1(8). The values can be:
    • group:name — the owner and members of group name
    • public — everyone 💫
🚨 Also important: if something goes wrong while reading a part of the configuration of a service directory, s6-svperms does not print the corresponding line to stdout. Instead it prints a warning message to stderr. So like, no silent failures, it's giving honest communication 💀

the "actually changing stuff" mode 🛠️

When you invoke it with the other options, s6-svperms modifies the permissions of the service directories listed in servicedirs..., exactly as specified by the options. And heads up: the same permissions get applied to all the services listed in servicedirs.... No picking favourites, periodt.

the safety rant (affectionate) 🧚

The default (restrictive) permissions are safe. Iconic. Keep them.

Unless the operation of a service is itself restricted information, it's also safe to make status: more permissive. Like, lowkey fine.

Opening control: to a group can be useful — for instance in a shared administration situation where individual administrators are not given full root powers. Very "we all have a job to do" of you. 💜

⚠️ But making events: public bears a small risk of a local DoS attack preventing more subscriptions to events. So it is not recommended for supervision trees where such subscriptions are critical to operations — such as a set of root services managed by s6-rc[1]. Not me warning you about your own architecture 😭

🦋 OPTIONS 🦋

  • -v — re-read the permissions after writing them, and print them to stdout. a little echo, as a treat ✨
  • -u — restrict the status: and control: permissions to owner: only the owner of a service directory will be able to read its state or control the service. This is the default when s6-supervise(8) starts a service for the first time.
  • -g group — allow members of group group to read the status of the service, but not to control it — control stays restricted to the owner.
  • -G group — allow members of group group to read and control the service. full access bestie 💅
  • -o — allow everyone to read the status of the service, but restrict control: to the owner.
  • -O group — allow everyone to read the status, and allow members of group group to control the service.
  • -e — allow everyone to subscribe to events. 🌈
  • -E group — only allow members of group group to subscribe to events. This is the default when s6-supervise(8) starts a service for the first time, with group being the primary group of the s6-supervise(8) process (most likely root).

Oh and about group — normally it's a group name that gets searched in the group database. But if it starts with a colon (:), the rest of group is interpreted as a numerical gid, and the group database will not be read. sneaky shortcut, love that for you 🍓

⭐ EXIT STATUS ⭐

  • 0 — Success. slay.
  • 1 — Something went wrong when reading permissions in one of the service directories.
  • 100 — Wrong usage. 🙈
  • 111 — System call failed.

💖 SEE ALSO 💖

This man page is ported from the authoritative documentation at: https://skarnet.org/software/s6/s6-svperms.html

👑 AUTHORS 👑

  • Laurent Bercot
  • Alexis <flexibeast@gmail.com> (man page port)

okay that's the whole page bestie, go forth and configure responsibly 🫶💅✨ — brought to you by Debian, dated September 29, 2021, filing under S6-SVPERMS(8). mwah 💋

📦 where this page comes from