Control: severity -1 important On Mon, Mar 07, 2022 at 10:12:01PM +0100, Marc Haber wrote: > I would suggest making both options do the same, just not setting a > password for the newly created account, document this, and emit in the > --disabled-login case a warning that logins might still be possible for > the account. A NEWS.Debian entry is probably in order. > > In the future, we might have a new option, for example > --no-set-password, and deprecate both old versions of the options. > > afaics, the code path selected by adduser --system does not honor either > option anyway and just does not set a password. If this is true, this > should be documented as well. I a not sure whether we should issue a > warning if adduser --system --disabled-(password|login) is called.
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. - --disabled-login and an explicitly set --shell is an error and will be flagged as such. Greetings Marc
