Bug#1004710: Invoke "useradd -r" when creating a system user
On Fri, 2022-02-25 at 02:45 -0600, Daniel Lewart wrote: > Also "sudo apt install openssh-server" warns: > useradd warning: sshd's uid 116 outside of the UID_MIN 1000 and > UID_MAX 6 range. Daniel: Thanks for making note of this. Using "-r" does solve the issue, but more needs to be done to ensure that other functionality is not altered unintentionally. To those interested, a fix for this is pending review and will be included in the next upload. -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
Debian Adduser Developers,
Also "sudo apt install openssh-server" warns:
useradd warning: sshd's uid 116 outside of the UID_MIN 1000 and
UID_MAX 6 range.
Tested patch which keeps options in alphabetic order is below.
Thank you!
Daniel Lewart
Urbana, Illinois
---
diff -ru a/usr/sbin/adduser b/usr/sbin/adduser
--- a/usr/sbin/adduser2018-09-15 14:12:39.0 -0500
+++ b/usr/sbin/adduser2022-02-25 00:00:00.0 -0600
@@ -434,7 +434,7 @@
$shell = $special_shell || '/usr/sbin/nologin';
$undouser = $new_name;
my $useradd = &which('useradd');
-&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-s',
+&systemcall($useradd, '-d', $home_dir, '-g', $ingroup_name, '-r', '-s',
$shell, '-u', $new_uid, $new_name);
if(!$disabled_login) {
my $usermod = &which('usermod');
Bug#1004710: Invoke "useradd -r" when creating a system user
On Tue, 2022-02-22 at 15:02 +0100, Marc Haber wrote: > adduser --system should enforce policy for system users. The local > administrator is free to ignore Debian policy as they see fit. adduser > should not enforce things on the local admin that don't apply to them. > > Maybe we add, some time in the future, an option --ignore-policy that a > local admin can use, so that maintainer scripts get the support of > policy enforcement. I agree with this. The strictness should be something that can be disabled if the local administrator so desires. > > If useradd is intended to replace adduser, I would like to know as most > > of my work would be lessened in importance. > > I don't think there is any such intention in Debian. There is simply no > mechanism to bring this forward other than talking and convincing each > and every package maintainer. It would be a ton of work. That's for sure. -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, Feb 13, 2022 at 01:52:14PM -0500, Jason Franklin wrote: > On Sun, 2022-02-13 at 19:18 +0100, Marc Haber wrote: > > On Sun, Feb 13, 2022 at 12:27:26PM -0500, Jason Franklin wrote: > > > That warning is not emitted here when "-r" is added to the call made > > > from within adduser. The range discrepancy needs to be sorted out with > > > discussion, I think. > > > > Policy also helps here, it's rather explicit in defining the uid ranges. > > Are we in line with policy? > > Adduser is in line with policy for the moment. Improvements can be made > in this regard. > > For example, some UIDs are explicitly forbidden by policy, but adduser > and useradd allow them. These should be blocked, and tests should be > written to prove this. adduser --system should enforce policy for system users. The local administrator is free to ignore Debian policy as they see fit. adduser should not enforce things on the local admin that don't apply to them. Maybe we add, some time in the future, an option --ignore-policy that a local admin can use, so that maintainer scripts get the support of policy enforcement. > > Useradd is more and more taking over functionality that has > > traditionally been implemented in adduser. Maybe they're working towards > > adduser just being a shim for backwards compatibility. Do you want me to > > reach out to them? > > Please do. You were faster than me, that's fine. > I am actually a bit worried that my work is in vain. The useradd utility > does have quite a few features that clash with or overtake those > previously offered by adduser. Adduser is used by over 1000 Debian packages and explicitly mentioned in policy (9.2.2, "packages SHOULD use adduser --system")). There is zero indication that this is going to change any time soon. There might other tools be available that allow creation of system users, but adduser is most probably going to stay the canonical tool for doing so. > If useradd is intended to replace adduser, I would like to know as most > of my work would be lessened in importance. I don't think there is any such intention in Debian. There is simply no mechanism to bring this forward other than talking and convincing each and every package maintainer. > I'm a bit uncertain as to where I stand in this regard. You're a member of the maintainer team of the "leading" user creating tool in Debian. You can decide whether to simplify your code by relying more on useradd int the future or not. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-20 at 10:03 +0100, Ricardo Fraile wrote: > Only to point that adduser is the recommended way to handle accounts in > maintainer scripts [1] and Debian Code Search reports 267 packages using > it [2], but dh_sysusers [3] seems to handle the same task on the > packages and works with useradd under the hood too. There is certainly some work to be done to reconcile the three different ways of managing users. There needs to be: - a "right way" to add a system user from a package - a "right way" to add a system user from the command line - a "right way" to do low-level user management tasks I had envisioned "adduser" as a Debian policy enforcer on top of the more distribution-agnostic tools from shadow. But, it is true now that some features are confusingly duplicated across these methods. Notably, there are settings for system user UID ranges in both /etc/login.defs and /etc/adduser.conf. There may be value in keeping "adduser" as a higher level tool that can do helpful things by default (e.g., avoid forbidden UIDs, avoid UID reuse, do additional clean up of at jobs w/o need for configs, etc.). I am unsure how to proceed, but I know it will require working well with the shadow maintainers. I think I'll start a discussion through the proper channel. Thanks! -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
Only to point that adduser is the recommended way to handle accounts in maintainer scripts [1] and Debian Code Search reports 267 packages using it [2], but dh_sysusers [3] seems to handle the same task on the packages and works with useradd under the hood too. [1] - https://wiki.debian.org/AccountHandlingInMaintainerScripts [2] - https://codesearch.debian.net/search?q=path%3Adebian%2F*postinst+adduser&literal=1&perpkg=1 [3] - https://manpages.debian.org/testing/dh-sysuser/dh_sysuser.1.en.html Regards, Ricardo F.
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-13 at 19:18 +0100, Marc Haber wrote: > On Sun, Feb 13, 2022 at 12:27:26PM -0500, Jason Franklin wrote: > > That warning is not emitted here when "-r" is added to the call made > > from within adduser. The range discrepancy needs to be sorted out with > > discussion, I think. > > Policy also helps here, it's rather explicit in defining the uid ranges. > Are we in line with policy? Adduser is in line with policy for the moment. Improvements can be made in this regard. For example, some UIDs are explicitly forbidden by policy, but adduser and useradd allow them. These should be blocked, and tests should be written to prove this. > Useradd is more and more taking over functionality that has > traditionally been implemented in adduser. Maybe they're working towards > adduser just being a shim for backwards compatibility. Do you want me to > reach out to them? Please do. I am actually a bit worried that my work is in vain. The useradd utility does have quite a few features that clash with or overtake those previously offered by adduser. If useradd is intended to replace adduser, I would like to know as most of my work would be lessened in importance. The questions is: Can adduser offer features that admins want and that useradd lacks? I think the answer to the above question is "yes", but we need to make sure we know what these additional features are. :/ I'm a bit uncertain as to where I stand in this regard. Thanks, -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, Feb 13, 2022 at 12:27:26PM -0500, Jason Franklin wrote: > That warning is not emitted here when "-r" is added to the call made > from within adduser. The range discrepancy needs to be sorted out with > discussion, I think. Policy also helps here, it's rather explicit in defining the uid ranges. Are we in line with policy? Useradd is more and more taking over functionality that has traditionally been implemented in adduser. Maybe they're working towards adduser just being a shim for backwards compatibility. Do you want me to reach out to them? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-13 at 18:14 +0100, Marc Haber wrote: > Should useradd emit a warning in this case? I mean, we WANT the low UID > in this case. Is it inside the limits of a low-level tool to impose its > own standards on the system or is this possible a bug in useradd? As part of this bug, we will need to have a conversation with the "login" maintainers about how these ranges are to be configured. Currently, useradd has its own range settings in /etc/login.defs, and adduser has its own in /etc/adduser.conf. adduser can be written to ignore the former completely in its useradd invocation. However, having such a setting in two places may be a bit confusing. That warning is not emitted here when "-r" is added to the call made from within adduser. The range discrepancy needs to be sorted out with discussion, I think. -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, Feb 13, 2022 at 12:09:44PM -0500, Jason Franklin wrote: > I also came across this warning when investigating this bug. > > When I get this bug fixed, the warning will go away. Should useradd emit a warning in this case? I mean, we WANT the low UID in this case. Is it inside the limits of a low-level tool to impose its own standards on the system or is this possible a bug in useradd? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1004710: Invoke "useradd -r" when creating a system user
On Sun, 2022-02-13 at 16:04 +0100, Ricardo Fraile wrote: > Adding _tuptime user... > useradd warning: _tuptime's uid 106 outside of the UID_MIN 1000 and UID_MAX > 6 range. > Created symlink /etc/systemd/system/multi-user.target.wants/tuptime.service → > /lib/systemd/system/tuptime.service. > Processing triggers for man-db (2.10.0-2) ... > >* What outcome did you expect instead? > Install the package without "useradd warning" prompt. Ricardo: I also came across this warning when investigating this bug. When I get this bug fixed, the warning will go away. Thanks! -- Jason Franklin
Bug#1004710: Invoke "useradd -r" when creating a system user
Package: adduser Version: 3.118 Followup-For: Bug #1004710 X-Debbugs-Cc: rfra...@rfraile.eu Dear Maintainer, I think that I received a warning related to this issue. This is the related information: * What led up to the situation? Installing tuptime package * What exactly did you do (or not do) that was effective (or ineffective)? apt install tuptime * What was the outcome of this action? # apt install tuptime Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: tuptime 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 28.7 kB of archives. After this operation, 96.3 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian bookworm/main amd64 tuptime all 5.1.0 [28.7 kB] Fetched 28.7 kB in 0s (467 kB/s) Selecting previously unselected package tuptime. (Reading database ... 28281 files and directories currently installed.) Preparing to unpack .../archives/tuptime_5.1.0_all.deb ... Unpacking tuptime (5.1.0) ... Setting up tuptime (5.1.0) ... Adding _tuptime user... useradd warning: _tuptime's uid 106 outside of the UID_MIN 1000 and UID_MAX 6 range. Created symlink /etc/systemd/system/multi-user.target.wants/tuptime.service → /lib/systemd/system/tuptime.service. Processing triggers for man-db (2.10.0-2) ... * What outcome did you expect instead? Install the package without "useradd warning" prompt. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages adduser depends on: ii debconf [debconf-2.0] 1.5.79 ii passwd 1:4.11.1+dfsg1-1 adduser recommends no packages. Versions of packages adduser suggests: ii liblocale-gettext-perl 1.07-4+b2 ii perl5.34.0-3 -- debconf information excluded
