On Sat, Mar 19, 2022 at 11:44:05AM +0100, Marc Haber wrote: > After discussion in policy and on debian-devel, this is what adduser is > going to do: > > - document (README.adduser-for-packages, adduser(8)) that > --disabled-login and --disabled-password are only defined for > non-system accounts. --system accounts get an invalid password and > /usr/sbin/nologin unless explicitly requested otherwise regardless of > the --disabled options. Many packages have adduser --system > --disabled-(login|password) in their maintainer scripts so we cannot > change this behavior. > - document (adduser(8)) that --disabled-login will just not set a > password and leave the password in the state that useradd created. > - change and document (adduser(8)) that --disabled-password will behave > like --disabled-login and additionally set the shell to > /usr/sbin/nologin.
FYI, this broke openssh's autopkgtests. I've pushed https://salsa.debian.org/ssh-team/openssh/-/commit/af3ead2202 to fix that. I don't think this affects normal use of OpenSSH in Debian. The relevant code only runs when UsePAM is disabled, and it so happens that the way we enable UsePAM by default in Debian is via the default /etc/ssh/sshd_config, but the regression tests use their own sshd_config which we don't patch. (It may be worth looking into running the regression tests with something closer to Debian's default sshd_config at some point; I hadn't noticed this discrepancy until today.) However, it could affect systems where the admin has disabled UsePAM. I'm not sure I really follow the logic of why the behaviour of --disabled-password was changed in this particular way; but at any rate, I thought I'd mention this particular observed breakage in case you weren't aware of it. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
