> So long as you're able to start arbitrary binaries from the shell
> you're given though, you are not be forced to use a vendor shell.

Well, yeah, almost.  There's a problem only when I want shell scripts
written for vendor shells to work.  Otherwise just setting it to sh and
creating a .profile

	case $# in
		0)	exec /my/shell ;;
		*)	exec /my/shell "$@" ;;
	esac

will do.  But I can't do that without losing sh scripts, and I can't
use csh without losing csh scripts.

>> What is /etc/shells good for?  Anything?  Or is it just following a
>> tradition started by someone looking for a quick fix?

> I find it very useful in order that I can allow various shell choices
> to general purpose users (and disallow others).

Yeah, but all you can do is allow a few and disallow all others.  You
can't allow all and disallow a few or none.

>> Even if it still has some use, I'd really like to see a way that I,
>> as a sysadmin, can configure it such that _any_ program is
>> considered a "standard shell".
> Would a '*' do the trick for you if it was implemented?

Yeah, but it can't be, 'cause getusershell()'s design is bad.
Regardless of what you do to getusershell() and friends, it is not
possible to implement any "allow by default" policy without hacking on
all callers of getusershell().

> I'd like to see a missing file mean that chsh was disabled too.  The
> internal list in getusershell() is truely bogus and should call for
> another PR in my opinion.

I'd like to see each thing that cares have its own configuration
mechanism, and getusershell() and /etc/shells go away entirely.  Most
of them have their own configuration files anyway (eg, ftpd)...and the
ones that don't probably should.  (For example, someone mentioned
yppasswdd.  I'd like to be able to configure yppasswdd to disallow all
shell changes, but allow local shell changes.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D