>My objection here is roughly the same. /sbin/nologin does not mean
>"locked out", it's a non-shell that can serve as a shell. While there
>may be some value in chsh disallowing a change *from* /sbin/nologin to
>something else by the own user, it's not intended to block any access at
>all by a user -- it's canonical purpose allowed FTP logins successfully,
>for example.
OK. I understand what you're saying. I suppose this boils down to what
"nologin" is supposed to mean.
1. On the one hand, we have the behaviour of Fedora (and RHEL and
CentOS) since 2002, with nologin in /etc/shells, which is as you
describe.
2. On the other hand, we have nologin as introduced by 4.4BSD and copied
by Linux, including the original RedHat distro itself before Fedora
days: nologin is absent from /etc/shells, and setting it does disable
all access.
I am sure that disallowing logins while still allowing FTP was *not* the
original canonical purpose of nologin in 4.4BSD. Indeed, there is a
currently open ticket [1] to remove this text from the shells(5) man
page:
Be aware that there are programs which consult this file to
find out if a user is a normal user; for example, FTP daemons
traditionally disallow access to users with shells not included
in this file.
This text, of course, also appears in all those other Linux distros
where nologin is not in /etc/shells.
>To prevent an 'su' specification of shell and to prevent any login, one
>can use /bin/false easily enough (which, again, was historical practice
>AFAIK). To prevent login via password (or an 'su' from one local user to
>another), usermod -L would seem to be more correct.
It's true that we used to use /bin/false to disable shell access. I
wasn't there at the time, but I imagine the reason nologin was invented
was to make it clear to a user that their account has been disabled by
printing a message, rather than just mysteriously kicking them out.
It's also true that locking the password is a good idea if you want to
definitively disable an account. However, on all other systems except
Fedora and friends, nologin alone does seem to be sufficient.
(Of course, ssh with key-based access does not respect locked passwords,
although I've just discovered it does respect expired accounts. It would
seem that "usermod -e 1 -s /sbin/nologin -L user" is the belt and braces
approach to disabling an account!)
>My concern here is that we're losing a useful tool: a built-in
>"non-shell" shell, functioning as a middle-ground between an invalid
>shell and an account lockout.
Well, you do of course have the option of adding nologin back into
/etc/shells, or supplying your own program to do the job and listing
*that* in shells. You could even try to get such a thing into the core
distribution, but please don't call "nologin", as that is confusing to
anyone that's used to *BSD, Debian, etc.
I contend that we have this middle ground by historical accident, not by
design. If it were by design, surely all those system accounts (bin,
daemon, adm, etc) would have the "definitely no access" shell,
/bin/false or whatever, and not the "middle ground" shell of nologin?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1218302
Toby
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
