On Wed, Jul 13, 2022 at 11:00:11PM +0200, Marc Haber wrote: > 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.
Sounds reasonable. > 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. Sure. I had thought that expiry would be sufficient. However, if you are saving state after locking, it is simple enough to use the nologin shell as another hardening step. > 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. Proceed, of course! Slowness on my part shouldn't hold things up! ;) Best, -- Jason Franklin
