Subject: Re: bin/2905: setting environment vars from login
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
List: current-users
Date: 11/17/1996 09:09:01
>> What is /etc/shells good for?  Anything?  Or is it just following a
>> tradition started by someone looking for a quick fix?

> I can think of at least one problem that would arise if /etc/shells
> wasnt used to restrict chsh's:

>   - yppasswdd could be used to change your shell from
>     a special restricted shell to a full access shell.

> yppasswd needs only the account name, the new shell and the account
> pasword.  Currently it makes sure that both the old shell and the new
> shell are in /etc/shells before doing anything.

This is not so much an argument for /etc/shells as it is perceiving
that yppasswdd is yet another program that needs a configuration
mechanism for recognizing what accounts should be considered "captive"
for its purposes.  /etc/shells is only a partial solution to that
problem (witness how many programs have some other configuration file
in addition to checking getusershell()), and in its current
implementation (ie, getusershell()) it renders completely impossible an
otherwise reasonable administrative decision, namely, "all executables
are to be considered valid shells".  (Sure, there are lots of setups
where this would be a stupid decision, but there are also plenty where
it's not.)

The problem with getusershell() is that the interface inherently
assumes that you want to restrict by default.  If you want to permit by
default, either allowing all shells or forbidding only a few,
getusershell() cannot be made to serve.  You need a call more along the
lines of "int valid_user_shell_p(const char *)".

					der Mouse

		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D