On Wed, Jul 13, 2022 at 10:18:55PM +0200, Marc Haber wrote: > are you progressing here? If not, I'd like to tackle this with some low > priority.
Unfortunately, I have not made any progress on this yet. Too many personal things in the way... > 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. 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. > 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! :) -- Jason Franklin
