Bug#948115: Revise init script Policy based on GR result

[Sam Hartman]

Russ said off-list he was ready for seconds.
I second his patch with the status being encouraged rather than
recommended change.
In seconding, my primary review criteria was whether I thought the
change accurately reflected what the GR conclusion was.

--Sam


signature.asc
Description: PGP signature

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Sam Hartman  writes:

> One question:

> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole. This provision is intended to provide flexibility to balance the
> +quality standards of the distribution against the release schedule and the
> +importance of making a stable release.

> I wonder if that should be can (or is permitted) rather than may.

Good point.  I agree with your analysis and will change this in my draft
version to "The Release Team can".

-- 
Russ Allbery (r...@debian.org)  

Bug#948115: Revise init script Policy based on GR result

[Russ Allbery]

Sam Hartman  writes:

> I've reviewed your patch.
> It looks good.

> One minor suggestion:

> +The ``start``, ``stop``, ``restart``, and ``force-reload`` options should
> +be supported by all init scripts. Supporting ``status`` is recommended but
> +not required. The ``reload`` and ``try-restart`` options are optional.

> How about supporting status is encouraged.
> At this point in the game, do we really want people opening bugs because
> an init script doesn't support status?

> Besides that, LGTM.

I agree with that change and will make that in my version.  Other folks
reviewing this patch, please consider that change as made when deciding
whether to second (and let me know if you object to that change).

Thank you for the review!

-- 
Russ Allbery (r...@debian.org)  

Re: Guidance on solving the username namespacing problem

[Russ Allbery]

Philipp Kern  writes:

> OpenBSD rather successfully standardized on the underscore prefix to
> eliminate this conflict altogether. I would like that we recommend the
> same thing.

I agree.

> The main question that has been raised was how to manage the migration.

I agree with this too.  I'm happy to have Policy standardize this
convention ASAP for newly-created users and then think at more leisure
about whether (and if so, how) to migrate existing users.

> I think the priority should be on stopping the bleeding and new users
> should follow a consistent scheme, but I understand how without a
> migration plan we just end up with "one more scheme" (even if it might
> be the most popular now except using none at all[1]).

In this particular case, I don't think standardizing one of the many
schemes in use would cause problems over the current situation even if we
don't go back and make everything consistent.

> I tried to raise this issue in [2] a year ago, but I think I don't know
> how to even start drafting a policy snippet about this. Would it be
> sufficient to just mandate "In order to avoid collisions with accounts
> created by the system administrator, usernames created by packages
> should start with an underscore." (assuming we could get a rough
> consensus for something like that) in 9.2.1 for now?

Yes.  I think we should say something about how packages that started
creating users before this recommendation was added don't need to change
the name of that user (until we figure out a migration strategy).

-- 
Russ Allbery (r...@debian.org)  

Re: Guidance on solving the username namespacing problem

[Simon McVittie]

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 6-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 6-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 6-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 6-64999 ranges,
and maybe to future allocations in the 0-99 

Re: Guidance on solving the username namespacing problem

[Sam Hartman]

> "Philipp" == Philipp Kern  writes:

Philipp> I tried to raise this issue in [2] a year ago, but I think I don't 
know
Philipp> how to even start drafting a policy snippet about this. Would it be
Philipp> sufficient to just mandate "In order to avoid collisions with 
accounts
Philipp> created by the system administrator, usernames created by packages
Philipp> should start with an underscore." (assuming we could get a rough
Philipp> consensus for something like that) in 9.2.1 for now? Or is this
Philipp> effectively infeasible until we come up with a good migration 
story?

I think you could certainly do  usernames created by packages are
encouraged to start with an underscore.

Encouraged being the new normative word meaning that maintainers ought
to do x unless they have a reason (like an existing username) to do
something else.

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.

Intent there is to capture making it a bug to do something else for new
usernames without making requirements for existing names.

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.

Bug#948115: Revise init script Policy based on GR result

[Sam Hartman]

I've reviewed your patch.
It looks good.

One minor suggestion:

+The ``start``, ``stop``, ``restart``, and ``force-reload`` options should
+be supported by all init scripts. Supporting ``status`` is recommended but
+not required. The ``reload`` and ``try-restart`` options are optional.

How about supporting status is encouraged.
At this point in the game, do we really want people opening bugs because
an init script doesn't support status?

Besides that, LGTM.

Bug#944920: Revise terminology used to specify requirements

[Sam Hartman]

Russ, I've reviewed your new patch.

I haven't been participating in this discussion before, but I think it
is fair to say that I have significant experience with these sorts of
normative language discussions and Debian policy in general.

I agree with all your changes (with one question below).
My review was insufficient to catch changes you should hav made but did
not.

One question:

+The Release Team may, at their discretion, downgrade a Policy requirement
+to a Policy recommendation for a given release of the Debian distribution.
+This may be done for only a specific package or for the archive as a
+whole. This provision is intended to provide flexibility to balance the
+quality standards of the distribution against the release schedule and the
+importance of making a stable release.

I wonder if that should be can (or is permitted) rather than may.
Saying it is optional implies that the policy is not making a
recommendation on whether they should make such changes.
I guess that's true, but either:

1) it's in scope for the policy to permit this.  In which case may is
too weak.

2) It's out of scope, in which you should not use normative language at
all.

Some will argue that it's inherently out of scope for you to make that
recommendation because of separation of concerns between the policy
editors and release team.
I think it would be inappropriate for the policy editors to update what
policy says about what the release team can do without sign-off from the
release team  (or change in the delegation text).  For example it would
clearly be inappropriate for the policy editors to change "is permitted"
to "must not" in the above without the release team agreeing.
But I think whether policy makes normative documentation in this space
should be decided based on what is best for the project rather than on
who all would have to approve such changes.

That said, can is simpler.

Regardless of may, can, or is permitted, I second your patch.


signature.asc
Description: PGP signature

Re: Guidance on solving the username namespacing problem

[Philipp Kern]

(And then my broken keyboard driver caused this to be sent prematurely.
But alas, it's out now.)

On 1/4/2020 1:52 PM, Philipp Kern wrote:
> [Please cc me on replies as I am not currently subscribed to the list.]
> 
> 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.
> 
> There are some well-known usernames like "root" that are a given for an
> organization to block. But there are many usernames dynamically created
> by applications. DynamicUser would solve part of the problem, but some
> services need to persist data and sometimes it is useful to reference a
> fixed identity even outside of a filesystem context (e.g. in iptables
> rules). At my organization we had collisions with regular usernames -
> e.g. a user legitimately called themselves "bind" because part of their
> name was "Bin". Debian does not maintain a complete list of such
> usernames and it is even hard to compute from the packages right now,
> given that the users are created from maintainer scripts and sometimes
> are even configured from Debconf (which is another arbitrary indirection).
> 
> OpenBSD rather successfully standardized on the underscore prefix to
> eliminate this conflict altogether. I would like that we recommend the
> same thing.
> 
> 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, but I understand how without a
> migration plan we just end up with "one more scheme" (even if it might
> be the most popular now except using none at all[1]).
> 
> I tried to raise this issue in [2] a year ago, but I think I don't know
> how to even start drafting a policy snippet about this. Would it be
> sufficient to just mandate "In order to avoid collisions with accounts
> created by the system administrator, usernames created by packages
> should start with an underscore." (assuming we could get a rough
> consensus for something like that) in 9.2.1 for now? Or is this
> effectively infeasible until we come up with a good migration story?

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.

In the end what I'm looking for is input from the policy editors on how
to possibly approach this. Especially as AIUI policy is supposed to
document current consensus rather than necessarily set the standards.

Kind regards
Philipp Kern

Guidance on solving the username namespacing problem

[Philipp Kern]

[Please cc me on replies as I am not currently subscribed to the list.]

Hi,

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.

There are some well-known usernames like "root" that are a given for an
organization to block. But there are many usernames dynamically created
by applications. DynamicUser would solve part of the problem, but some
services need to persist data and sometimes it is useful to reference a
fixed identity even outside of a filesystem context (e.g. in iptables
rules). At my organization we had collisions with regular usernames -
e.g. a user legitimately called themselves "bind" because part of their
name was "Bin". Debian does not maintain a complete list of such
usernames and it is even hard to compute from the packages right now,
given that the users are created from maintainer scripts and sometimes
are even configured from Debconf (which is another arbitrary indirection).

OpenBSD rather successfully standardized on the underscore prefix to
eliminate this conflict altogether. I would like that we recommend the
same thing.

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, but I understand how without a
migration plan we just end up with "one more scheme" (even if it might
be the most popular now except using none at all[1]).

I tried to raise this issue in [2] a year ago, but I think I don't know
how to even start drafting a policy snippet about this. Would it be
sufficient to just mandate "In order to avoid collisions with accounts
created by the system administrator, usernames created by packages
should start with an underscore." (assuming we could get a rough
consensus for something like that) in 9.2.1 for now? Or is this
effectively infeasible until we come up with a good migration story?

Kind regards
Philipp Kern

[1] https://people.debian.org/~pkern/permanent/userlist.txt
[2] https://lists.debian.org/debian-devel/2019/02/msg00131.html and
following