sysusers: properly mark generated accounts as locked #13277
Conversation
Previously, we'd only set the shell to /usr/bin/nologin and lock the
password for system users. Let's go one step further and also lock the
whole account.
This is a paranoid safety precaution, since neither disabling the shell
like this nor disabling the password is sufficient to lock an account,
since remote shell tools generally allow passing different shells, and
logins into ftp or similar protocols don't know the shell concept anyway.
Moreover, in times of ssh authentication by password is just one
option of authentication among many.
Takes inspiration from the recommendations in usermod(8)'s -L switch:
"Note: if you wish to lock the account (not only access with a
password), you should also set the EXPIRE_DATE to 1."
|
Ack, seems reasonable to do this. |
|
Note that this seems to break at least gdm: https://bugs.archlinux.org/task/63706 Arch Linux uses a sysusers file to create the gdm user account as part of the package installation process... |
|
cf. #13522 |
|
metoo I'm about as conflicted as to what is the right solution here. For now I'm throwing this into Clear Linux OS: https://gist.github.com/ahkok/98d0a32383a5e7f121f223053575cdfd |
|
This change broke all my scripts using "su postgres -c command" because postgres account is now created as "expired" account in new installation of Arch linux. And su now does not run the script stating that user account has expired. Am I doing anything wrong by using su? |
|
Yeah, I don't think we should lock the account. Let's revert this. (In particular, this is a clear compatibility break.) |
This reverts the gist of commit 636e72b. The comment and the tiny cleanup are left alone. We shouldn't lock the accounts because people actually need to use them, and if they are locked, various tools will refuse. See systemd#13277 (comment) and follow-up comments.
|
See #13813. |
|
Honestly I'm still a fan of being able to lock down many accounts. Note that we've locked down even postgres in Clear Linux (and provided workarounds for Long term I think we want sysusers.d to support locking accounts? |
|
Yeah, but it should be opt-in, for backwards compatiblity. |
This reverts the gist of commit 636e72b. The comment and the tiny cleanup are left alone. We shouldn't lock the accounts because people actually need to use them, and if they are locked, various tools will refuse. See #13277 (comment) and follow-up comments.
This reverts the gist of commit 636e72b. The comment and the tiny cleanup are left alone. We shouldn't lock the accounts because people actually need to use them, and if they are locked, various tools will refuse. See systemd/systemd#13277 (comment) and follow-up comments. (cherry picked from commit 12c8293)
Previously, we'd only set the shell to /usr/bin/nologin and lock the
password for system users. Let's go one step further and also lock the
whole account.
This is a paranoid safety precaution, since neither disabling the shell
like this nor disabling the password is sufficient to lock an account,
since remote shell tools generally allow passing different shells, and
logins into ftp or similar protocols don't know the shell concept anyway.
Moreover, in times of ssh authentication by password is just one
option of authentication among many.
Takes inspiration from the recommendations in usermod(8)'s -L switch: