On Tue, Jan 03, 2023 at 03:04:22PM +0100, Marc Haber wrote: > On Mon, Jan 02, 2023 at 11:04:22PM +0000, Colin Watson wrote: > > 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. > > Thanks for fixing that. We literally discussed that over a time of > weeks, in public, and had to guess a lot about how PAM and ssh handle > the different state of accounts, and it's sad that this opportunity was > not picked up by the ssh team, leaving the decision to us as adduser > team.
I'm afraid I didn't notice the discussion - in practice the SSH team is pretty much just me, I'd only just returned from some business travel, March tends to be a pretty busy time of year for me, and I don't think anyone CCed me or otherwise alerted me that my input was needed (apologies if that did actually happen and I missed it). Though I must admit that I'm a little confused even after reading up on it: https://lists.debian.org/debian-devel/2022/03/msg00304.html seems to be a summing-up of the thread, in which you wrote '--disabled-password will result in a "*" in /etc/shadow, effectively making it impossible to use any password based authentication', but that seems to be the opposite of what was implemented (it used to be "*", but is now "!"). So even if I had noticed the discussion at the time, I might very well have got to the end of it and concluded that there wasn't going to be a problem. It's also of course possible that I wouldn't have noticed the issue until autopkgtests started to fail, since I don't normally pay a lot of attention to the non-UsePAM case. > Since this is a matter that you can only do wrong, if you want that > changed, please carry this to the TC to get advice. I think you may have misread my tone a bit? I'm not particularly cross or anything like that and I'm not necessarily agitating for this to be changed, just neutrally informing you of a particular regression that you might otherwise not have been aware of and might wish to take into account if it lines up with other feedback you get. You likely have a better overview of the situation around this than I do. > > 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.) > > It would actually be good if testing would resemble the actual > environment that Debian installed. Isn't that somewaht the idea of > testing? Oh, I quite agree, I just wanted to get the immediate regression fixed first. I've pushed https://salsa.debian.org/ssh-team/openssh/-/commit/51c2542824 to fix this. > > but at any rate, > > I thought I'd mention this particular observed breakage in case you > > weren't aware of it. > > Thank you very much. Do you think this is worth mentioning in > NEWS.Debian? If I were you, I'd be inclined to do so if only to reduce time spent on support issues in future, but obviously it's up to you. (Actually, my own inclination would probably be to put it in the manual page so that it's right there for anyone looking up what --disabled-password means.) Thanks, -- Colin Watson (he/him) [[email protected]]
