>
> We don't need to worry about state, since for a system account, after
> adduser --system, we have the shell set to /usr/bin/nologin and the
> expity date at 99999. Any package maintainer wanting it differently
> would explicitly spell that out in her postinst, reinstating the account
> to their specification without having us to worry
Thanks for clarifying, that's good to know. Another thought I had: do we
want adduser --unlock --system to fall back to creating the account anyway,
if it doesn't exist (at least by default).. the resulting behavior being
that installing a package that shares a common system user that was
previously disabled will enable it on installation - I'm not sure which is
less surprising, will defer to you if you think usermod -Ue99999 is
sufficient.
m
On Thu, Feb 20, 2025 at 12:27 PM Marc Haber <mh+debian-packa...@zugschlus.de>
wrote:
> On Thu, Feb 20, 2025 at 10:02:56AM -0500, Matt Barry wrote:
> > > deluser --lock => usermod -lock. Nothing else.
> > > deluser --system --lock => usermod -lock. Nothing else.
> >
> >
> > > adduser --unlock => usermod --unlock. Nothing else.
> > > adduser --system --unlock => usermod --unlock. Nothing else.
> >
> >
> > So to reiterate for the record:
> > - locking does nothing to expiration or login shell, crontabs, doesn't
> back
> > up or remove any files.
> > - locking an account reversibly invalidates the password via usermod
>
> I actually thought that we could rely on usermod doing the right thing.
> It's so nice when something becomes somebody else's problem ;-)
>
> But after reading your points I think you're right.
>
> > - any account can be locked;
>
> Yes.
>
> >system accounts can be set to lock
>
> instead of being deleted
>
> > by default
> > in /etc/deluser.conf.
> >
> > I do apologize if this has already been hashed out, but is password
> > invalidation enough, *especially* for system users where unpassworded
> > services/crons/etc are the primary use case? Those would still run
> unless
> > we change the shell.
>
> Hm. Probably even with the shell changed if it's a systemd service or a
> timer.
>
> >And public key authentication via ssh, for that
> > matter.. the more I think about it, the more I think that at the very
> least
> > we should also expire the account, ie. usermod --lock --expiredate
> > $last_friday_night
> >
> > fwiw, this is what I had written before I saw your feedback:
> >
> > &systemcall('/usr/sbin/usermod', "-e", $exp_date, "-f", 0, "-L", "-s",
> > "/usr/bin/nologin", $user);
>
> If expiring the account and changing the shell will disable systemd
> timers, services etc as well, then we could do that. But we need to
> verify that.
>
> We don't need to worry about state, since for a system account, after
> adduser --system, we have the shell set to /usr/bin/nologin and the
> expity date at 99999. Any package maintainer wanting it differently
> would explicitly spell that out in her postinst, reinstating the account
> to their specification without having us to worry
>
> 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
>
