On Fri, September 30, 2016 3:16 am, Toby Goodwin wrote:
As a member of the "remove nologin from /etc/shells"
faction, I have 2
technical reasons for my position. I don't think either of these points
have been addressed by the "leave it in" faction.
1. Certain programs use pam_shells to check access, but without requiring
that the shell is able to run commands. So far I've found vsftpd and
proftpd, and I'd expect all ftp daemons to follow suit. With nologin in
/etc/shells, these programs will grant access to nologin users. I find
this
behaviour "surprising". In general it's better for security features to
default to the least permissive setting.
The thing is, this is a well-known usage for /sbin/nologin -- one of the
two canonical cases (the other being for the display of a polite message
when a login is attempted). I understand that someone might find this
"surprising", but... I've found a lot of things surprising over the years
in Linux. I don't see why that justifies changing a 14 y/o default. Plenty
of others may find its removal that much more surprising.
At a certain point, "bugs" turn into features and known, if not
particularly greatly documented, behaviors. I think this is the case here.
2. It's often been said that Unix allows you to shoot yourself in
the
foot,
but I can't think of anything else a normal user can do that's quite as
simple and drastic as "chsh -s /sbin/nologin".
1. As originally proposed [1], the change of adding nologin to
/etc/shells
was to allow it to be set with chsh. But in modern Fedora root is allowed
to do so anyway, and I don't think it's a bug that normal users cannot
permanently lock themselves out in this way.
I've actually done this on a few rare occasions; I needed to do some final
creation of a system account's directory structure, didn't want to bother
with a recursive chown and verification of umask afterwards, and removed
the default shell after me.
I've also done it a few times to prevent simple logins from certain
externally-automated accounts while I'm doing maintenance, as it's quicker
than exiting back to root to do it then su'ing back in if I happen to be
on the box.
I can imagine cases where on larger multiuser systems a step like this
could be performed by local policy. Places are weird.
I do understand that it's weird, but why are we intentionally disabling
people's ability to do "weird" things arbitrarily? A sense of aesthetics?
Finally, all change has a cost; this now forces Yet Another Conditional
out there in people's config/automation scripts for reasons of rather
questionable importance. The fact that that's been something of the mantra
of Fedora's over the past 6 years doesn't mean we need to keep on doing
that.
-jc