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
>>> approac
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 a
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 serv
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 wi
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
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 s
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
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?
>
I'd like to support the _user convention as well.
It works well as packages move around between distributions and things
get upstreamed.
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 sugg
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
> collisio
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 complicatin
❦ 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
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
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 cour
15 matches
Mail list logo
