Re: "valid shell"s

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

>> [...getusershell() issues...]
> One can also hack around the issue with a program in /usr/local/bin
> that execs $HOME/.shell, or /shells/$USER, which can then be
> anything.

True.  But that feels an awful lot like building a bridge over the back
fence because the front door is stuck: the right fix is to fix the
problem, not build kludgery to work around it.

> My guess is that otherwise it's not really worth trying to fix it,
> beyond maybe adding globbing.  Ultimately, there are too many admins
> and users who know how /etc/shells works to justify making big
> changes without a clear increment in functionality.

I believe I can fix it without breaking existing setups.  For example,
it could use /etc/shells as its config file, which works just the way
it does now unless the first line is "ShellsV2", in which case a bunch
of extended syntax is available.  Since all traditional /etc/shells
lines begin with / or #, or are blank, this shouldn't break existing
setups.  (Perhaps "*V2*" would be better....)

> My guess is that if you have enough users that adding random things
> they want to /etc/shells is a hassle, you also have enough users that
> the hassles associated with cleaning up after people who stupidly or
> accidentally set their shell to /bin/cat (or /usr/pgk/bin/zsh) will
> outweigh any administrative benefits of making chsh unrestricted.

Perhaps - but note I mentioned at least two plausible paradigms that
wouldn't permit /usr/pgk/bin/zsh, and one that wouldn't permit
/bin/cat, as well as the "unrestricted" one.  (Another one might be
"any existing name ending in `sh' is permitted", which stops most of
the typos and idiocies while still being unrestricted for most
purposes, though admittedly it's not proof against *malicious* idiots,
who can set their shells to yppush or xrefresh or the like.)

But since when has it been our job to render it imopssible for admins
to make more work for themselves? :-)  As X puts it, "mechanism, not
policy" - even if you and I think a policy is stupid for some reason,
that alone is not necessarily a reason to forbid it; someone may have
an unusual setup, or a reason neither of us has thought of why it's
actually a good idea.  "Unix does not prevent you from doing stupid
things because that would also prevent you from doing clever things."
We still ship telnet, and it's just one uncomment in /etc/inetd.conf
from being turned on.  Should we remove that, too, because admins can
shoot themselves in the foot with unsecured telnet?

I'll have a stab at redesigning and reimplementing and come back when I
have something concrete.  Maintaining existing functionality for
existing /etc/shells files will be a design goal.

/~\ 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