[just writing the bug report after realizing that that one forwards to adduser@p.d.o anyway]
On Wed, Jul 27, 2022 at 05:52:03PM -0400, Matt Barry wrote: > On Wed, 2022-07-27 at 15:21 +0200, Marc Haber wrote: > > On Wed, Jul 27, 2022 at 09:12:50AM -0400, Jason Franklin wrote: > > For a normal user account, I am undecided whether: > > > > - leave login shell intact, leaving a possible security hole > > - set login shell back to the default when the account gets reenabled > > - save login shell somewhere to reinstate if on reenabling. > > Maybe have adduser prompt when using --unlock (and without -s) whether > to reset the shell to the default? (just #2, but more explicit) If we don't have state, what would be the alternative to setting it back to default? I'd say a warning that the shell is being reset to the default. > Then again a single colon-separated file to check *before* selecting > the default isn't a ton of added complexity. Yes, we need some kind of state sooner or later anyway, so we'll have /var/lib/adduser anyway. > Contrary to the behavior of usermod(8), I personally think adding the > additional barrier to access is a feature. The additional barrier of having nologin as a shell, you mean? Just making sure. 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
