Re: "valid shell"s

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

>> then its backend(s) could support things like "anything is valid" or
>> "anything in /usr/local/shells/ is valid" or "anything in a
>> directory that's root-owned and non-world-writable all the way from
>> / is valid" as well as "these specific paths are valid".
> Can't you just add globbing to the existing interface, like:
>     /usr/local/shells/*

That addresses only one of my three examples (the second), and,
depending on the reading, only part of even that one (depending on
whether "anything in $FOO" means "any file directly in directory $FOO"
or "any file in or under directory $FOO").

Glob patterns would probably be one of the ways to configure a
validusershell() backend.  I don't think they should be the only one.

Come to think of it, another reaosnable policy might be "anything owned
by the user whose shell is being considered", which would mean that
validusershell() would need some sort of user ID.  I wonder if there
sbould be some kind of application ID as well (ftpd, chsh, etc)?  It
sounds reasonable, but it also sounds like second-system effect....

But then, better yet might be to get rid of getusershell() entirely in
favour of saner ways of solving its original problem (the security bug
of inserting new records in /etc/passwd via arbitrary chsh - at least
that was the justification I saw for it back when it first reared its
ugly head).  Yes, lots of things (eg, ftpd) use getusershell() for
other purposes, but IMO they are all abuses, based on equating "user
has a `valid shell'" with "user should be allowed to use service $FOO".

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