Re: Namespace for system users

[Philipp Kern]

Hi,

On 2/9/2019 6:02 PM, Sean Whitton wrote:
> On Sat 09 Feb 2019 at 01:51PM +01, Guillem Jover wrote:
> 
>> To that effect I sent a patch to adduser to allow these in #521883,
>> but it seems that's stuck. :/
>>
>>> How do others deal with this problem? Could someone think of a viable
>>> approach on how to approach this from a policy side?
>>
>> Unfortunately, last time it looked like there was some push bach, due
>> to there not being a clear winner in "current" practice at the time
>> AFAIR. I think a way forward would be to get that adduser patch merged,
>> then keep promoting the underscore usage, and possibly try to switch
>> existing users to use that.
> 
> ISTM to me we have a consensus, at least, that new packages with system
> users should use the underscore prefix convention.  There isn't a
> consensus on what to do about old packages, but Policy can be written in
> such a way to refer only to new packages with system users.

that sounds great to me. I think we should finally come up with a
solution and flesh out how to grandfather in the old packages, while
nudging them to adopt a new scheme if possible. Marco's approach is
ultimately correct in that maintainers of packages with existing system
users should evaluate if something can be done - but it might well be
that it is pretty much impossible to fix for some of the packages. And
that's fine.

I do wonder if it would be possible to solve some of the rename cases
with some sort of dpkg-maintscript-helper so that not everyone needs to
figure this out on their own, but I fear that this could easily be
ratholed into a too generic solution that supports all cases - which
would not be useful.

I did a small evaluation on the set of the existing users created by
packages in sid and put it onto [0]. It's a large list of ~300 users to
exclude while skipping the ones with dashes and underscores in them. I'd
be great to stop the bleeding here, though.

It's a bit sad that the policy bug #248809 did not go anywhere with the
last update happening in 2008. And obviously the list is now much larger
than the list compiled by Vincent back then. Is that the bug in which we
should continue this discussion for the policy change?

> Ideally the adduser change would happen before we wrote this down in
> Policy, but since the adduser behaviour is easy to workaround (IIRC), it
> would not be required for it to happen first.

The former maintainer of the package seems to have been sympathetic to
the patch in [1], too.

Kind regards and thanks
Philipp Kern

[0] https://people.debian.org/~pkern/permanent/userlist.txt -- Obviously
this still contains some variables at the top that would need manual
analysis. I also ignored all of OpenStack which seems to have its own
way of shipping a shell library in every postinst script that calls adduser.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521883#38

Re: Namespace for system users

[Ondřej Surý]

Oh, at first I thought you meant sysusers.d, but the DynamicUsers feature is 
useful only for really simple daemons with little interactions to the rest of 
the system and few state files.

One size doesn’t fit all and for daemons like cyrus-imapd (or other imap 
daemons) that need 770 on sockets and have zillion files in the spool, it would 
not play well with changing users at every start.

Ondrej 
--
Ondřej Surý 

> On 10 Feb 2019, at 10:28, Scott Leggett  wrote:
> 
>> On 2019-02-10.09:08, Ondřej Surý wrote:
>> This is fairly easy to be scripted (same as with tmpfiles).
>> 
>> I would like to see this adopted, but I am not sure how that solves the 
>> namespace problem.
>> 
> 
> Well the point is that the need to create system users can be avoided
> entirely by running services using only dynamic UIDs.
> 
> -- 
> Regards,
> Scott Leggett.

Re: Namespace for system users

[Scott Leggett]

On 2019-02-10.09:08, Ondřej Surý wrote:
> This is fairly easy to be scripted (same as with tmpfiles).
> 
> I would like to see this adopted, but I am not sure how that solves the 
> namespace problem.
> 

Well the point is that the need to create system users can be avoided
entirely by running services using only dynamic UIDs.

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Re: Namespace for system users

[Ondřej Surý]

This is fairly easy to be scripted (same as with tmpfiles).

I would like to see this adopted, but I am not sure how that solves the 
namespace problem.

Ondrej
--
Ondřej Surý 

> On 10 Feb 2019, at 05:45, Scott Leggett  wrote:
> 
>> On 2019-02-09.13:10, Philipp Kern wrote:
>> How do others deal with this problem? Could someone think of a viable
>> approach on how to approach this from a policy side?
> 
> systemd has an elegant solution for this problem, which I would like to
> see more widely adopted:
> 
> http://0pointer.net/blog/dynamic-users-with-systemd.html
> 
> The down-side, of course, is supporting other init systems..
> 
> -- 
> Regards,
> Scott Leggett.

Re: Namespace for system users

[Scott Leggett]

On 2019-02-09.13:10, Philipp Kern wrote:
> How do others deal with this problem? Could someone think of a viable
> approach on how to approach this from a policy side?

systemd has an elegant solution for this problem, which I would like to
see more widely adopted:

http://0pointer.net/blog/dynamic-users-with-systemd.html

The down-side, of course, is supporting other init systems..

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Re: Namespace for system users

[Marco d'Itri]

On Feb 09, Sean Whitton  wrote:

> ISTM to me we have a consensus, at least, that new packages with system
> users should use the underscore prefix convention.  There isn't a
> consensus on what to do about old packages, but Policy can be written in
> such a way to refer only to new packages with system users.
I think that each maintainer should evaluate how hard it would be to 
change the usernames created by their packages, e.g. by speculating if 
it is likely to be referenced by scripts or other packages.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Namespace for system users

[Russ Allbery]

Sam Hartman  writes:

> I'd like to support the _user convention as well.
> It works well as packages move around between distributions and things
> get upstreamed.

Agreed.  I think we should just write this up as the recommended approach
for all new system users in Policy.

(Changing the existing ones is sadly a much more complicated problem.)

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

Re: Namespace for system users

[Sean Whitton]

Hello,

On Sat 09 Feb 2019 at 01:51PM +01, Guillem Jover wrote:

> To that effect I sent a patch to adduser to allow these in #521883,
> but it seems that's stuck. :/
>
>> How do others deal with this problem? Could someone think of a viable
>> approach on how to approach this from a policy side?
>
> Unfortunately, last time it looked like there was some push bach, due
> to there not being a clear winner in "current" practice at the time
> AFAIR. I think a way forward would be to get that adduser patch merged,
> then keep promoting the underscore usage, and possibly try to switch
> existing users to use that.

ISTM to me we have a consensus, at least, that new packages with system
users should use the underscore prefix convention.  There isn't a
consensus on what to do about old packages, but Policy can be written in
such a way to refer only to new packages with system users.

Ideally the adduser change would happen before we wrote this down in
Policy, but since the adduser behaviour is easy to workaround (IIRC), it
would not be required for it to happen first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Namespace for system users

[Sam Hartman]

I'd like to support the _user convention as well.
It works well as packages move around between distributions and things
get upstreamed.

Re: Namespace for system users

[Holger Levsen]

On Sat, Feb 09, 2019 at 01:34:41PM +0100, Vincent Bernat wrote:
> This is a recurring topic. See:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248809

in addition to this -policy bug there is also #399028
"developers-reference: best practices to create and delete system
accounts" which suggests to include or refer to
https://wiki.debian.org/AccountHandlingInMaintainerScripts

Personally, I like the _apt convention.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Namespace for system users

[Guillem Jover]

Hi!

On Sat, 2019-02-09 at 13:10:27 +0100, Philipp Kern wrote:
> at work we have a large fleet of Debian machines, but also more than 200k
> user accounts with no reuse and somewhat painful rename experiences.
> Obviously an increasing number of accounts leads to a much increased risk of
> collisions with system users as created by Debian packages.

Yes. :(

> Of course it is easy to precompile a basic list to ban users from taking
> names like postfix, bind, or sshd. But it will never be exhaustive, packages
> are still free to come up with random names and users are free to install
> them and see things break.
> 
> Some core packages recently adding system users resorted to names like
> systemd-$daemon and _apt, which both address my concerns - as you can come
> up with simple rules like "no user might include [-_] in their username". On
> the other hand I know that Debian-* was painful and annoying for exim, but I
> suspect mostly because of the length of the username and tools dealing
> poorly with >8 character usernames. I think FreeBSD (among others?) picked
> the underscore at the front of the username. Intuitively that feels like a
> somewhat clean proposal that is also friendly to derivatives.

This has been discussed in the past (several times I think), the last
incarnation (AFAIR) started at:

  

IMO the only sensible option is to use the underscore prefix
convention. Because it is:

 - vendor neutral, so less unnatural on say downstreams/forks
 - has precedent on other systems, so less surprising
 - short, so does cause less display/truncation issues
 - less ugly

To that effect I sent a patch to adduser to allow these in #521883,
but it seems that's stuck. :/

> How do others deal with this problem? Could someone think of a viable
> approach on how to approach this from a policy side?

Unfortunately, last time it looked like there was some push bach, due
to there not being a clear winner in "current" practice at the time
AFAIR. I think a way forward would be to get that adduser patch merged,
then keep promoting the underscore usage, and possibly try to switch
existing users to use that.

Thanks,
Guillem

Re: Namespace for system users

[Simon McVittie]

On Sat, 09 Feb 2019 at 13:10:27 +0100, Philipp Kern wrote:
> Obviously an increasing number of accounts leads to a much increased risk of
> collisions with system users as created by Debian packages.

This topic comes up every so often and doesn't ever seem to come to a
conclusion.

One complicating factor is that after a package has created its system
user, renaming that system user is difficult and has a high regression
risk, so most packages that already have a system user will need a
permanent exception from whatever naming policy we choose.

> I think FreeBSD (among others?) picked
> the underscore at the front of the username. Intuitively that feels like a
> somewhat clean proposal that is also friendly to derivatives.

This seems a good idea to me, and if I remember correctly, it is the
closest there has been to a consensus. _apt is a prominent example.

Names that contain a dash and are namespaced by the name of an upstream
project (systemd-network, libvirt-qemu, quake2-server) or are namespaced
by Debian (Debian-gdm, debian-tor) also seem reasonably unlikely to
collide.

I think it would be a good idea to deprecate system user names that don't have
any particular punctuation (avahi, clamav, messagebus, uuidd), although again,
fixing existing instances of this anti-pattern is problematic.

smcv

Re: Namespace for system users

[Vincent Bernat]

 ❦  9 février 2019 13:10 +01, Philipp Kern :

> Some core packages recently adding system users resorted to names like
> systemd-$daemon and _apt, which both address my concerns - as you can
> come up with simple rules like "no user might include [-_] in their
> username". On the other hand I know that Debian-* was painful and
> annoying for exim, but I suspect mostly because of the length of the
> username and tools dealing poorly with >8 character usernames. I think
> FreeBSD (among others?) picked the underscore at the front of the
> username. Intuitively that feels like a somewhat clean proposal that
> is also friendly to derivatives.
>
> How do others deal with this problem? Could someone think of a viable
> approach on how to approach this from a policy side?

This is a recurring topic. See:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248809
-- 
Noise proves nothing.  Often a hen who has merely laid an egg cackles
as if she laid an asteroid.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Namespace for system users

[W. Martin Borgert]

On 2019-02-09 13:10, Philipp Kern wrote:
> How do others deal with this problem?

In my company, we use leading underscore for all non-human
accounts. Human accounts get lower-case ASCII letters only.

Also, we use the same uid/gid for the same human user on all
machines (1000 + something unique, e.g. numerical employee id).

Namespace for system users

[Philipp Kern]

Hi,

at work we have a large fleet of Debian machines, but also more than 
200k user accounts with no reuse and somewhat painful rename 
experiences. Obviously an increasing number of accounts leads to a much 
increased risk of collisions with system users as created by Debian 
packages.


Of course it is easy to precompile a basic list to ban users from taking 
names like postfix, bind, or sshd. But it will never be exhaustive, 
packages are still free to come up with random names and users are free 
to install them and see things break.


Some core packages recently adding system users resorted to names like 
systemd-$daemon and _apt, which both address my concerns - as you can 
come up with simple rules like "no user might include [-_] in their 
username". On the other hand I know that Debian-* was painful and 
annoying for exim, but I suspect mostly because of the length of the 
username and tools dealing poorly with >8 character usernames. I think 
FreeBSD (among others?) picked the underscore at the front of the 
username. Intuitively that feels like a somewhat clean proposal that is 
also friendly to derivatives.


How do others deal with this problem? Could someone think of a viable 
approach on how to approach this from a policy side?


Kind regards and thanks
Philipp Kern