Hi,
On Thu, 2022-07-07 at 08:48 +0200, Marc Haber wrote:
> > >
> > > Can you come up with a better default for users created with
> > > adduser
> > > --system without requesting a dedicated group?
> >
> > One idea worth considering, imho, is what the reporter [0]
> > suggests:
> > make --group the default for --system.
>
> I don't like that idea at all, it'll introduce an avalanche of new
> groups. That should be in the responsibility of the individual
> package
> maintainer.
>From users-and-groups.txt.gz:
LSB 1.3 lists daemon as legacy, and says: "The 'daemon'
UID/GID was used as an unprivileged UID/GID for daemons
to execute under in order to limit their access to the
system. Generally daemons should now run under
individual UID/GIDs in order to further partition
daemons from one another."
Users have to have *some* gid (you can add a non-existent one manually
in the passwd database, but no tools will allow it). Whether is
"nogroup" or "daemon" is irrelevant, security-wise; only an unshared
(or deliberately shared) resource is an improvement.
I don't love the idea of adding hundreds of new system users (it is
hundreds, not thousands), but I don't see additional alternatives.
Then again, also from users-and-groups.txt.gz:
(Technically speaking, it does no harm for a file to be
owned by group nogroup as long as the ownership confers
no additional privileges, that is if the group and other
permission bits are equal. However, this is sloppy
practice and should be avoided.)
So.. the status quo is at least acknowledged. It would nice if we
could confirm that nobody is at any point *relying* on 'nogroup', but
that seems likely to be true. Leaving it as is simply puts the
decision back on maintainers to decide whether 'nogroup' is acceptable
in their case.
> > Sysadmin hat, I can think of situations
> > where having a dedicated service group is useful (eg. giving r/o
> > access
> > to logs).
>
> We do have the adm group for that.
Which grants blanket access, whereas a service group could offer a more
precise access level. (This is however not a strong argument in favor
of changing the current default, imho.)
Cheers,
Matt
