• [adduser] default group for 'dynamically allocated system users'

    From Marc Haber@21:1/5 to All on Mon Jul 4 09:20:01 2022
    Hi,

    adduser has been putting newly created 'dynamically allocated system
    users' (adduser --system) into the nogroup group. It is also
    documented to do so. There is an ancient bug report complaining about
    this, and I think this is a valid complaint. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz says that no files
    should ever be owned by nogroup, making adduser do the right thing in
    its current state.

    Can you come up with a better default for users created with adduser
    --system without requesting a dedicated group?

    Greetings
    Marc
    --
    -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
    Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matt Barry@21:1/5 to Marc Haber on Wed Jul 6 21:30:01 2022
    Hi!

    On Mon, 2022-07-04 at 09:12 +0200, Marc Haber wrote:
    Hi,

    adduser has been putting newly created 'dynamically allocated system
    users' (adduser --system) into the nogroup group. It is also
    documented to do so. There is an ancient bug report complaining about
    this, and I think this is a valid complaint. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz says that no files
    should ever be owned by nogroup, making adduser do the right thing in
    its current state.

    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.

    This will add one group for every system user (that is currently
    created without --group).. not unreasonable overhead for slightly
    improved security posture. Sysadmin hat, I can think of situations
    where having a dedicated service group is useful (eg. giving r/o access
    to logs).

    Having two unrelated services share a GID is just an unnecessary risk;
    probably should not be the default.


    Greetings
    Marc

    Cheers,
    Matt


    [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693218

    -----BEGIN PGP SIGNATURE-----

    iQJKBAABCgA0FiEEnnn62mSvqqi3CaOCyHh1RhnOe48FAmLF4J8WHG1hdHRAaGF6 ZWxtb2xsdXNrLm9yZwAKCRDIeHVGGc57j+7FD/97ZBmf+54OVYH/YT6017dhnxyq AnoJn/NDEJGEe5flJJjTHqeP2YQp9DVx8RnMniW+9LW6t4qO65WkYPKJ6zZooBz0 4gi2uml8onPj5RO8YTZZwgRxVL8ZSmZ/YBFEFFl4MyjGkNEdWH1SOtgFFVDylLzn 1wmSgUxbuOmhy5nO7RCV5kTQnCdBycRqzAl6BwV6Rfbi/nPuQhp5eWUCRnvlJUlj Mp9ScjeJJwNJZIjUgiL6eSPZmtNqy9DwH2oh7c7s2TrsDS/DXk/TXjHOm+C1Y3c3 Kzp6fCol7JURAjYfuTsrFVqaREE0NHA5at+8ITsRLQtUBMvT0i9Yr8EmDTSjmKQT Qwb8luecrlyST8nDCX4TBxZ59iSfLotwz3OSqRh1KCx7UPqGAfoW0rXmTpz6EjnE DvuxskUGhvf3WkMXlyBK7Y9ex/uLJdXI0ouRZc2s++Hh7P8cFP05hh01qojmnRbP YdmTUgm39QmLtWvuajlO42CQ93nm4btKi+7u9RNcceZx4wR+oEtD7z9zmLHxwdjw 56w7E83YuucBQJnGGHzoXgvsuHXqagheVfT6RkszRZ5sakHw68qpUIM+H3REKY6H VFl/6jrECjIVgpyKxVU+i8P6GyOVw7upB6sqrX06LDVuNJ9FrVn6brVZ1b+YnSAg KRK8kx6xyE4vv5bnZw==
    =D/9h
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marc Haber@21:1/5 to All on Thu Jul 7 08:50:01 2022
    On Wed, 06 Jul 2022 15:21:03 -0400, Matt Barry <matt@hazelmollusk.org>
    wrote:
    On Mon, 2022-07-04 at 09:12 +0200, Marc Haber wrote:
    adduser has been putting newly created 'dynamically allocated system
    users' (adduser --system) into the nogroup group. It is also
    documented to do so. There is an ancient bug report complaining about
    this, and I think this is a valid complaint. However,
    /usr/share/doc/base-passwd/users-and-groups.txt.gz says that no files
    should ever be owned by nogroup, making adduser do the right thing in
    its current state.

    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.

    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.

    Greetings
    Marc
    --
    -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
    Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matt Barry@21:1/5 to Marc Haber on Thu Jul 7 18:10:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)