Re: "valid shell"s

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

On Wed, Feb 06, 2008 at 01:42:21AM -0500, der Mouse wrote:
 > > 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.
 > 
 > ...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? 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.

 > > 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 - and I gather it won't, if you're suggesting kludgery like a
 > "shell" that just execs the real shell - 

I don't see how it can without sacrificing functionality. A lot of
programs check for "a valid shell" for an assortment of reasons; you
can't remove the concept of a valid shell without providing a suitable
alternate check for these cases.

 > I'd like to at least make it
 > possible for people who agree with me to easily make go away on their
 > own systems.  *I* can set up such a wrapper shell easily enough, but
 > most admins are not system programmers.  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.

 > > 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.
 > 
 > Depending on what you're trying to do with that list, you might.
 > Depending on whether programmers can set it on more-or-less arbitrary
 > programs they write, either some admins will want to forbid some
 > programs that have it set or some (other) admins will want to allow
 > some programs that don't.
 > 
 > Besides, what does "the exec-level interface expected of a shell"
 > actually mean?  I'm having trouble thinking of anything which rsh (the
 > restricted sh, not the remote execution program) satisfies but, say, vi
 > or expect doesn't.

It means that the program supports the "sh foo", "sh -i", and "sh -c
cmd" interface that we generally expect from shells and that are
implicitly included in the behavior expected from su and perhaps other
place. Maybe it should also require that the program accepts user
input.

I know people who use vi as their shell.

(Restricted shells are an exercise in futility, however.)

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