Re: Guidance on solving the username namespacing problem
On Sat, 04 Jan 2020 at 13:52:51 +0100, Philipp Kern wrote:
> now that we are talking again about standardizing user creation using
> sysusers, I wonder if you could give me any guidance on how to attack
> the Debian system user namespacing problem.
It's a good reminder, but I think the naming convention for system users
is mostly orthogonal to whether they're created by adduser, useradd,
systemd-sysusers or something else. (But see below for DynamicUser.)
> OpenBSD rather successfully standardized on the underscore prefix to
> eliminate this conflict altogether. I would like that we recommend the
> same thing.
I agree that's a good convention for new system users (better than
debian- or Debian-, and a lot better than having no particular prefix),
particularly now that apt creates _apt on basically every Debian-derived
system.
> The main question that has been raised was how to manage the migration.
> I think the priority should be on stopping the bleeding and new users
> should follow a consistent scheme
I agree, and I don't think the absence of a migration path for existing
system users like messagebus and systemd-coredump should prevent us
from encouraging the OpenBSD underscore thing for new system users
like _apt and _flatpak.
I maintain several game servers that use undesirable usernames like
Debian-openarena, which might make good test subjects for automatic
migration to names like _openarena in relatively unimportant packages
(we shouldn't be using more important packages like dbus as our test
subjects). After successfully prototyping it in a couple of packages,
the right place for it would probably be debhelper or init-system-helpers.
The thing to do during migration would probably be to add a second user
with the same uid and other details, but a different username (like
useradd --non-unique); then optionally remove the original user record,
leaving only the new name.
On Sat, 04 Jan 2020 at 13:55:40 +0100, Philipp Kern wrote:
> A more bold move would be to tell daemon packagers to use DynamicUser
> where feasible and only allocate more permanent users if there's a need
> for it.
I think this is *almost* orthogonal to how those users are named.
The only way in which DynamicUser affects the naming policy is that if
foo-bar.service uses DynamicUser=yes and does not specify a User, the
default is foo-bar. /lib/systemd/system/fwupd-refresh.service is currently
the only example on my laptop.
For units with a long, namespaced name like fwupd-refresh.service,
flatpak-system-helper.service and quake2-server.serice, this is probably
good enough in practice, even though in principle these names might collide.
Possible routes:
- leave these units with behaviour that does not follow the recommendation,
reasoning that if they have fairly long names it won't actually be a
practical problem
- recommend that units with DynamicUser=yes should specify a User and Group
that fit the naming convention, for example DynamicUser=yes,
User=_fwupd-refresh
- ask the systemd Debian maintainers to patch systemd so that it defaults
to the equivalent of User=_fwupd-refresh instead (note that this
behaviour change is in principle an API break which could conceivably
make services that work in other distributions fail to work in Debian,
although probably it would work fine in practice)
- ask systemd upstream to make that change (they could probably be persuaded
that the OpenBSD underscore thing is a good convention; same notes about
this being a behaviour change)
- avoid DynamicUser=yes
It's also worth noting that the 61184-65519 uid range used for DynamicUser
by default collides with the rarely-used 60000-64999 uid range for system
users that are "globally allocated by the Debian project, but only created
on demand". systemd avoids uids that are already in use when allocating
a DynamicUser, so the only time this is a practical problem is if systemd
has already used a uid for DynamicUser, and then the package to which that
uid is allocated in base-passwd gets installed before the next reboot.
The uids in range 60000-64999 that are really allocated in practice are
in the sub-range 64000-64062, except for 63434 'netplan' which appears
to be for an orphaned package that isn't in testing; so it might be
feasible to reconfigure the DynamicUser range to 60000-63999 or similar
in Debian's systemd?
On Sat, 04 Jan 2020 at 09:00:37 -0500, Sam Hartman wrote:
> I think you could certainly do usernames created by packages are
> encouraged to start with an underscore.
...
> You could also do something more complex like
>¯
> When maintainers choose a new hard-coded or dynamically generated username
> for packages to use, they should start this username with an underscore.
The latter sounds better to me, at least for now.
This should probably go somewhere near §9.2.2 "UID and GID classes":
it applies to future allocations in the 100-999 and 60000-64999 ranges,
and maybe to future allocations in the 0-99 range (although I don't think
we should be migrating existing low-uid hard-coded names like games and
proxy to _games and _proxy).
> Note that in cases like debconf, I don't think we want an underscore
> prepended to what the user chooses, although I think defaulting to
> something with a leading underscore would be fine.
Yes, if a debconf prompt asks "what username should be used for the
foo server?", it would seem appropriate to make the default _foo, but
if the user chooses foo-server, I think rewriting it to _foo-server
would be contrary to the principle of least astonishment.
smcv
Reply to: