On Sun, Aug 07, 2022 at 01:05:13PM -0400, Jason Franklin wrote: > On Wed, Jul 27, 2022 at 03:21:08PM +0200, Marc Haber wrote: > > > Before I start, I want to make sure we agree on what should be done. > > > > > > I asserted that two things were sufficient: > > > 1. Put a '!' in front of the user's password in /etc/shadow > > > 2. Expire the account > > > > > > This makes it trivial to unlock an account with all of its attributes > > > intact, including login shell. > > > > I think that having nologin as a shell has the advantage of giving a > > clear error message IF somebody manages to log in to the expired account > > with an invalid password. > > The message with /usr/sbin/nologin is indeed nice. On my system, I get > something like... > > | $ su --login foo > | Password: > | This account is currently not available.
Yes, that's what I'd like to have, but of course, if the account is password-locked and expired, getting at this point is already a bug. > With password locking plus account expiration, I get... > > | $ su --login fish > | Password: > | su: Authentication failure > > I find it odd that I get a password prompt for an account that is > expired, but so it is. I think that the idea is not to give information that an account is expired, indicating an unused accout. > My only reason for saying it's not necessary is that someone being able > to log in to an expired account would indicate a bug somewhere else that > should be fixed (in shadow, maybe?). If account expiration cannot be > relied upon, we have a bigger security concern, I think. I think so, and it's not our bug anyway, but it would probably be nice to implement Defense in Depth. > > For a normal user account, I am undecided whether: > > > > - leave login shell intact, leaving a possible security hole > > Again, this is where I am not so sure. > > If there is a security hole, it would be someone else's, right? Right. > Account expiration is either reliable or it is not. If a system account is migrated to a directory service (which is possible), we might not have write access to the account expiration data and to the hashed password. > > - set login shell back to the default when the account gets reenabled > > - save login shell somewhere to reinstate if on reenabling. > > > > I'd say, do it as you see fit, changing that at a later time would be a > > rather isolated change so I'm fine with going ahead either way here, > > while still having a personal preference for the third possibility, but > > I am not the one who decides that. > > This is fair. > > As soon as I'm done with the other bug I'm working on, I'll move to this > one and proceed with the stateless implementation. > > Saving and restoring a user's shell can be added later if needed. > > Sound good? Proceed, but please document that we are still considering to change login shell at a later time. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
