Re: "valid shell"s

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> ...and "whether accounts are real or not" - for just about any
>> definition of "real" - is not the correct thing to test if you want
>> to find out whether an account is allowed to use server-side FTP,
>> sendmail's prog mailer, etc.
> Isn't it?

It isn't.

> That's the entire premise behind checking the shell, as opposed to,
> say, /etc/ftpusers or other more verbose configuration files that do
> or could exist.

Equating those two is the premise behind abusing getusershell() to
check for things like "may use server-side FTP", yes.  But that
equation is invalid.

Using getusershell(3) - or even the validusershell() I sketched - as a
way of testing "is this user allowed to do server-side FTP" or "is this
user allowed to use sendmail's prog mailer" is basically assuming that
you have exactly two clases of user: (1) unrestricted users, who can do
"anything", and have "valid" shells, and (2) restricted users, who are
sufficiently special-purpose that they should be permitted nothing but
what their shell lets them at.  This is a broken paradigm, because
plenty of sites have more user classes than just those two, but it's
close enough for most sites to get by with it, which is what's allowed
it to survive this long.  (Even the sites that really would like more
have a tendency to shoehorn them into those two because that's what
support is available out of the box for.)

>>> Is it really worth mucking with the format of /etc/shells without
>>> fixing that?  That's what I was trying to get at.
>> Well, I *would* prefer to do away with it entirely.  But if that
>> won't happen - [...]
> I don't see how it can without sacrificing functionality.  A lot of
> programs check for "a valid shell" for an assortment of reasons;

And, possibly with the exception of chsh on systems that don't mind
breaking the "the shell is just another program" principle that is so
often touted as one of Unix's strengths, they are all checking X when
they mean Y because X is what a routine is readily available to test.

> you can't remove the concept of a valid shell without providing a
> suitable alternate check for these cases.

Actually, from a dogmatic point of view, the correct thing to do is to
wall them off from the "valid shell" concept, to make them stop abusing
it by equating it with other things.

Not that I expect NetBSD to go that route; "do it right" appears to
actually mean "do it right as long as it doesn't significantly
inconvenience more than a tiny number of people, and even them only if
they're judged sufficiently unimportant".

>> Or would you support putting such a wrapper in base?
> One could, but it seems superfluous.  Among other things, I'm not
> convinced that maintaining /etc/shells is such a major hassle that it
> warrants such action.

As a matter of principle, whether it's a hassle is irrelevant; it is
doing it wrong, and thus needs to be fixed.

As a matter of pragmatics, it makes it, among other things, impossible
to configure a box such that users in general have control over their
own shells; setting such a system up demands some coding in that case -
either writing the wrapper or removing the getusershell() stupidity
from (at least) chsh.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B