Re: "valid shell"s

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Feb 05, 2008 at 02:33:05AM -0500, der Mouse wrote:
 > >> [...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.

Yes, although sometimes (depending on what's wrong with the front
door) it is the most pragmatic approach.

 > > 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.

Yes, but as you noted, ultimately the shell field of the password file
is not the right place for encoding whether accounts are real or not.
Is it really worth mucking with the format of /etc/shells without
fixing that? That's what I was trying to get at. Visible configuration
changes, even compatible ones, carry a cost, and without fairly
substantial benefits it tends not to be a good tradeoff.

In a perfect world, programs that were shells would carry a type
marker of some kind saying "I implement the exec-level interface
expected of a shell", so you wouldn't need to maintain a list. That
world's a long way off, though.

-- 
David A. Holland
dholland%netbsd.org@localhost