Re: [PATCH] bug #10981: adduser -D behavior
On 2/12/20 6:07 AM, Didier Kryn wrote: > FYI, there has been for decades an adduser in Debian which is higher > level than useradd in the sense that it is a helper for admin. It > enforces local policy and can be used to change it: minimum userid, > default group, etc. Strange. Local policy via useradd is configured in /etc/login.defs If USERGROUPS_ENAB is defined as "yes", useradd will by default create a new group for each user, and add them to the group, and if it is defined as "no", then the GROUP setting in /etc/default/useradd (falling back to 100 by default) will be used as the GID which will be the newly created user's primary group. The minimum and maximum UID/GID pool is defined via this conf block: # # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 6 # System accounts SYS_UID_MIN 500 SYS_UID_MAX 999 # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 6 # System accounts SYS_GID_MIN 500 SYS_GID_MAX 999 ... I'm not sure what additional utility "adduser" would bring, given this is all already configurable. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
On 2/12/20 6:48 AM, Donovan Keohane wrote: > My apologies on the coreutils misnomer, adduser is provided by package > 'adduser' > in the Debian repos at least. There is not a direct issue with the > functional behavior of Busybox's adduser, it does properly skip the > password prompt and create an account with a disabled password. > > The issue lies in the symbolic meaning of '!' versus '*'. While both are > valid characters to create an impossible hash, '!' is used by 'passwd' to > denote a locked account. I don't think accounts with a disabled password > should be locked by default. Again: my point is that this is imitating the default behavior of useradd, with the addendum that it will prompt for a password during account creation. Do you propose to change the default behavior of the shadow project's useradd command too? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
My apologies on the coreutils misnomer, adduser is provided by package 'adduser' in the Debian repos at least. There is not a direct issue with the functional behavior of Busybox's adduser, it does properly skip the password prompt and create an account with a disabled password. The issue lies in the symbolic meaning of '!' versus '*'. While both are valid characters to create an impossible hash, '!' is used by 'passwd' to denote a locked account. I don't think accounts with a disabled password should be locked by default. On 2/11/20 9:36 AM, Eli Schwartz wrote: > On 2/11/20 8:13 AM, Donovan Keohane wrote: >> In adduser in coreutils, the behavior of --disabled-password sets the >> users hash in /etc/shadow to a single asterisk. It looks like busybox >> adduser '-D' option is supposed to be analogous to the behavior of >> coreutils '--disabled-password'. > > There is no coreutils "adduser" utility. util-linux does provide a > "useradd" utility, but it does not have any --disabled-password option. > On my Arch Linux system I cannot find any package which provides an > "adduser" utility at all, except for busybox which provides some > nonstandard applet in its multi-call binary, something the usual > repository search tool cannot pick up. > > I would have expected busybox adduser -D (why does this exist in a form > so different from the useradd command? At least it doesn't share the > same name, that would be confusing... then again I guess that is why the > unusual name) to do exactly what it I guess does, that is to say, it > disables the feature of automatically prompting for a password, which > means you will need to manually "passwd"/"chpasswd" in order to login. > This emulates the default behavior of util-linux useradd, which creates > an account with a disabled password, and expects you to passwd and > change it. > > Is there a problem with this behavior? > > > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox > ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
Le 12/02/2020 à 13:16, Eli Schwartz a écrit : On 2/12/20 6:07 AM, Didier Kryn wrote: FYI, there has been for decades an adduser in Debian which is higher level than useradd in the sense that it is a helper for admin. It enforces local policy and can be used to change it: minimum userid, default group, etc. Strange. Local policy via useradd is configured in /etc/login.defs If USERGROUPS_ENAB is defined as "yes", useradd will by default create a new group for each user, and add them to the group, and if it is defined as "no", then the GROUP setting in /etc/default/useradd (falling back to 100 by default) will be used as the GID which will be the newly created user's primary group. The minimum and maximum UID/GID pool is defined via this conf block: # # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 6 # System accounts SYS_UID_MIN 500 SYS_UID_MAX 999 # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 6 # System accounts SYS_GID_MIN 500 SYS_GID_MAX 999 ... I'm not sure what additional utility "adduser" would bring, given this is all already configurable. Well, I think there are more things configurable with adduser. And, by default, it enforces Debian policy. It always has been a problem for me to remember how it works and I always preferred useradd. And even using a hand-made script to implement my own defaults. Didier Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
Le 11/02/2020 à 15:36, Eli Schwartz a écrit : On 2/11/20 8:13 AM, Donovan Keohane wrote: In adduser in coreutils, the behavior of --disabled-password sets the users hash in /etc/shadow to a single asterisk. It looks like busybox adduser '-D' option is supposed to be analogous to the behavior of coreutils '--disabled-password'. There is no coreutils "adduser" utility. util-linux does provide a "useradd" utility, but it does not have any --disabled-password option. On my Arch Linux system I cannot find any package which provides an "adduser" utility at all, except for busybox which provides some nonstandard applet in its multi-call binary, something the usual repository search tool cannot pick up. I would have expected busybox adduser -D (why does this exist in a form so different from the useradd command? At least it doesn't share the same name, that would be confusing... then again I guess that is why the unusual name) to do exactly what it I guess does, that is to say, it disables the feature of automatically prompting for a password, which means you will need to manually "passwd"/"chpasswd" in order to login. This emulates the default behavior of util-linux useradd, which creates an account with a disabled password, and expects you to passwd and change it. Is there a problem with this behavior? FYI, there has been for decades an adduser in Debian which is higher level than useradd in the sense that it is a helper for admin. It enforces local policy and can be used to change it: minimum userid, default group, etc. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
On 2/11/20 3:36 PM, Eli Schwartz wrote: On 2/11/20 8:13 AM, Donovan Keohane wrote: In adduser in coreutils, the behavior of --disabled-password sets the users hash in /etc/shadow to a single asterisk. It looks like busybox adduser '-D' option is supposed to be analogous to the behavior of coreutils '--disabled-password'. Hi, bb's adduser was implemented and modified to mimic the behavior that at the time debian's adduser showed for the simple reason that at least for me using debian it was easier to test it that way. For more info on debian's adduser see the attached man page. This is also the reason that some defaults chosen are very debianish but also sane and fit most of the use cases. Command line options allow to manage corner cases and other desired behaviors. The -D option is more or less a synthesis of this two adduser options (can't say if they existed both in the past): --disabled-login Do not run passwd to set the password. The user won't be able to use her account until the password is set. --disabled-password Like --disabled-login, but logins are still possible (for example using SSH RSA keys) but not using password authentication. and it was first introduced with commit: https://git.busybox.net/busybox/commit/loginutils/adduser.c?id=f0f754aeaf47b416abba8206dd2632cf24bb94a3 in 2003 The default passwd was static const char default_passwd[] = "x" for /etc/passwd and fprintf(shadow, "%s:!:%ld:%ld:%ld:%ld:::\n" in /etc/shadow if shadow password support was enabled. At that time size did matter and If I recall correctly bb didn't support long options yet but debian's adduser only had long options therefore the options were chosen arbitrarily by the developers and stayed like that for the last 17 years. Hope this helps. Ciao, Tito There is no coreutils "adduser" utility. util-linux does provide a "useradd" utility, but it does not have any --disabled-password option. On my Arch Linux system I cannot find any package which provides an "adduser" utility at all, except for busybox which provides some nonstandard applet in its multi-call binary, something the usual repository search tool cannot pick up. I would have expected busybox adduser -D (why does this exist in a form so different from the useradd command? At least it doesn't share the same name, that would be confusing... then again I guess that is why the unusual name) to do exactly what it I guess does, that is to say, it disables the feature of automatically prompting for a password, which means you will need to manually "passwd"/"chpasswd" in order to login. This emulates the default behavior of util-linux useradd, which creates an account with a disabled password, and expects you to passwd and change it. Is there a problem with this behavior? ADDUSER(8) System Manager's Manual ADDUSER(8) NAME adduser, addgroup - add a user or group to the system SYNOPSIS adduser [options] [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] [--firstuid ID] [--lastuid ID] [--ingroup GROUP | --gid ID] [--disabled-password] [--disabled-login] [--gecos GECOS] [--add_extra_groups] user adduser --system [options] [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID] [--group | --ingroup GROUP | --gid ID] [--disabled-password] [--disabled-login] [--gecos GECOS] user addgroup [options] [--gid ID] group addgroup --system [options] [--gid ID] group adduser [options] user group COMMON OPTIONS [--quiet] [--debug] [--force-badname] [--help|-h] [--version] [--conf FILE] DESCRIPTION adduser and addgroup add users and groups to the system according to command line options and configuration information in /etc/adduser.conf. They are friendlier front ends to the low level tools like useradd, groupadd and usermod programs, by default choosing Debian policy conformant UID and GID values, creating a home directory with skeletal configuration, running a custom script, and other features. adduser and addgroup can be run in one of five modes: Add a normal user If called with one non-option argument and without the --system or --group options, adduser will add a normal user. adduser will choose the first available UID from the range specified for normal users in the configuration file. The UID can be overridden with the --uid option. The range specified in the configuration file may be overridden with the --firstuid and --lastuid options. By default, each user in Debian GNU/Linux is given a corresponding group with the same name. Usergroups allow group writable directories to be easily maintained by placing the appropriate users in the new group, setting the set-group-ID bit in the directory, and ensuring that all
