Solved Locked account and su interplay

R

rdog

(Resolved by looking at code, but for posterity)

The handbook mentions that locking an account makes it impossible to login (alternative to /usr/sbin/nologin shell).

The `pw` manpage mentions locking prepends a magic string to the password field in the password file.

But I also experience that for a locked user, `su theuser command` says `su: Sorry`.

Tracing the code:
- https://github.com/freebsd/freebsd-...566b3b6eb46bcbbc68adf01f/usr.bin/su/su.c#L344
- ... https://github.com/freebsd/freebsd-src/blob/main/contrib/openpam/lib/libpam/openpam_dispatch.c#L61
- ... checking of PAM_ACCOUNT chain ... pam_load_module ...
- /etc/pam.d/su -> "account" includes system
- /etc/pam.d/system -> mentions pam_unix.so
- ... https://github.com/freebsd/freebsd-...f/lib/libpam/modules/pam_unix/pam_unix.c#L195, bingo

The user in case was used as a service user. So the rc.subr `su -m user ...` is also prevented for locked users. Okay, nologin only then.
 
rdog said:
The handbook mentions that locking an account makes it impossible to login (alternative to /usr/sbin/nologin shell).

But I also experience that for a locked user, `su theuser command` says `su: Sorry`.
Click to expand...
Yes, that is the entire point of locking an account.

Code: 
     A password of ‘*’ indicates that password authentication is disabled for
     that account (logins through other forms of authentication, e.g., using
     ssh(1) keys, will still work).  The field only contains encrypted
     passwords, and ‘*’ can never be the result of encrypting a password.

     An encrypted password prefixed by ‘*LOCKED*’ means that the account is
     temporarily locked out and no one can log into it using any
     authentication.  For a convenient command-line interface to account
     locking, see pw(8).
passwd(5)
 
What confuses me, it seems there's a tiny bit of ambiguity lurking around the definition of "logging in".

login(1):
Code: 
    login – log into the computer
     ...
     Immediately after logging a user in, login displays the system copyright
     notice, the date and time the user last logged in, the message of the day
     as well as other information.  If the file .hushlogin exists in the
     user's home directory, all of these messages are suppressed.  This is to
     simplify logins for non-human users, such as uucp(1).

     The login utility enters information into the environment (see
     environ(7)) specifying the user's home directory (HOME), command
     interpreter (SHELL), search path (PATH), terminal type (TERM) and user
     name (both LOGNAME and USER).

Above makes it sound like "logging in" is one step (see "immediately after logging a user in"), and displaying motd and starting the shell is a subsequent step.

su(1) says:
Code: 
     The su utility requests appropriate user credentials via PAM and switches
     to that user ID (the default user is the superuser).  A shell is then
     executed.
This doesn't mention login.

So someone unaware might (wrongly) conclude, that not being able to log in is separate from not being able to execute command as that user. That said, I'm quite happy that locking disables the execution too (better to err on the safe side), just documenting what pieces of information led me to believe otherwise.
 
Well, to be fair, login(1) mentions
Code: 
     If no user is specified, or if a user is specified and authentication of
     the user fails, login prompts for a user name.  Authentication of users
     is configurable via pam(8).
and su(1) also mentions PAM usage. So it seems PAM is the binding piece of information. So maybe my mental model was missing that authentication is always going through PAM.
 
You must log in or register to reply here.
Back
Top