
Dynamic Users with systemd - XJ0OYtjb
http://0pointer.net/blog/dynamic-users-with-systemd.html
======
JdeBP
The underlying premises upon which the rest is based are somewhat
questionable, in my experience. I have a lot of dedicated user accounts for
services, including dedicated user accounts for log services, far more than
there are on _any_ systemd system. My highest UID is 1468. I am a mere 2% of
the distance to exhausting even the 16-bit ID space, let alone the full 32-bit
ID space that the operating system actually has. And that 2% figure is without
taking into account that on that particular machine these accounts have been
assigned IDs starting from 1003.

All of these are dealt with by the package installation/deinstallation
mechanisms, and my experience is that _those are_ what needs attention, with
better, or at least widespread, mechanisms for handling dedicated user
accounts as part of the installation/deinstallation process. The OpenBSD
package manager provides a @newuser mechanism for this, which does all of the
work of allocating and deallocating dedicated user accounts for services. On
other package managers, the process is a more involved and explicitly written
one, involving combinations of getent, pw, userdel, and useradd. These package
managers would benefit from tools that enable the same sort of one-liners for
this stuff that OpenBSD's package manager does. (I've written a library of
shell functions for my packages.)

Addressed this way, one still gets services running under the aegides of
dedicated user accounts that only own and can modify little to no part of the
filesystem, but with all of the allocation/deallocation and file/directory
ownership work done _once_ , statically, at installation/deinstallation time;
rather than _time and again_ dynamically at runtime.

It's a parallel of the _Do not parse configuration at runtime._ principle. _Do
not do package management tasks_ , such as per-package user ID assignment and
per-package directory creation/deletion, _at runtime_.

------
wahern
That's cool, though FWIW the idea of using a random UID isn't original; it's
how some well-written daemons achieve privilege separation, preventing
unprivileged slaves from being able to interact with each other without having
to resort to unportable (and often non-existent) capability extensions. You
don't need init to do this for you; you can literally just do
setuid(arc4random_uniform(5000) + 60000), perhaps after doing the common
startup tasks that often require privileges. (The problem with the systemd
approach is that you're already unprivileged when you're invoked, which can be
a major hurdle for non-trivial services which require unnecessarily complex
workarounds--e.g. resorting to D-Bus machinations for otherwise simple
privileged operations that you only needed in the first 30 lines of main().)

And a far simpler solution than bind mounts for achieving persistent files is
to use the traditional setgid bit on the shared directory with a persistent
group[1]. For example,

    
    
      mkdir /var/foo
      chown root:somegroup /var/foo
      chmod u=rwx,g=rwxs,o=rx /var/foo
    

You then either make that group the service process's GID or its supplementary
GID if want to randomize the GID. And make sure process umasks are set
correctly so newly created files are group writeable.

Altogether this is like three or four lines of code: 1) setgid or setgid +
setgroup, 2) setuid, and 3) umask.

You can do all of this, today, on any Unix, with any init system. You end up
with files owned by random UIDs, but systemd has no better solution than just
periodically chown'ing them.

[1] If you want persistent files then there's really no burden in having a
persistent group. It just makes sense.

~~~
db48x
Unless you need two such programs on the same machine, in which case they need
to coordinate somehow. Perhaps by having a third service which hands out the
ids as needed.

~~~
JdeBP
... or by having a shared-memory account database in a tmpfs at
/run/systemd/dynamic-uid/ . (-:

That idea, by the way, was invented more fully and more generally about a
decade and a half ago by Daniel Rench, who named it "userdir".

------
bandrami
What a breathtakingly stupid idea. It doesn't actually solve any of the
underlying problems with UID limitations, and it removes the possibility of
static analysis.

