On Wed, Jul 13, 2022 at 04:46:53PM -0400, Jason Franklin wrote: > On Wed, Jul 13, 2022 at 10:18:55PM +0200, Marc Haber wrote: > > If adduser --lock sets the shell to nologin, how would we restore the > > account? Setting shell to /bin/bash, allowing --unlock a --shell option? > > Or should we finally introduce a state directory /var/lib/adduser and > > save the shell here? > > I assume you mean to clarify the behavior of "deluser --lock" here.
Yes, of course. Stupid me. > Giving this some thought, I would not go the route of changing any of > the user's attributes like the login shell. > > My understanding is that truly locking an account requires two things: > 1. Place a "!" in front of the password field in /etc/shadow. > 2. Expire the account. > > The first makes the password invalid in a way that is easily reversible. > The commands "usermod -L foo" and "usermod -U foo" will disable and then > re-enable password authentication for user "foo" in this manner. > > The second requires setting the user's EXPIRE_DATE to 1. This should > disable other forms of authentication without modifying any info we > would want to save (except for the expire date). > > See usermod(8) and shadow(5) for more info on locking and expiry. > > The minimal satisfactory fix would be just a "--lock" option for the > deluser command which does both of the above. To undo this, an admin > would run "usermod -U foo" and then set the expire date for the account > according to site policy. I am not sure if there is a convenient command > for doing the latter. The expire dates are controlled by useradd's configuration file /etc/login.defs, and the format is documented, so there is nothing too wrong by just grepping the information from there. For a non-system account, we would re-establish the default expiration value, or we could save the expiration date in a state file and read it from there. Otoh, for a system account, we should probably just disable account expiration and document that adduser as a policy layer does not handle system accounts with an expiration date. We're going to need state for some requested features anyway, sooner or later. The nologin shell has the nice advantage of denying login _with_ _a_ _message_ should somebody be able to log in to the account by some other means that might be allowed by weird PAM and ssh stuff. I would like to do that anyway, albeid not being strictly necessary. > > Should we do that in adduser, or should we have a new binary moduser? > > Not sure how to answer this one. > > Like I say above, adding only the "--lock" option to deluser minimally > satisfies this new requirement. > > I would say it's up to you! :) That was a stupid question on my side. The primary use of lock / unlock is going to be package maintainer scripts, hence lock is a function of deluser, and unlock one of adduser. I'd like to claim that feature and work on it if you're ok with that. I'm going to create a branch deluser-lock and push frequently, so you can review what I am doing. I reserve the right to force-push that branch though. Greetings Marc
