On Fri, Feb 22, 2002 at 08:14:03PM -0500, Andrew Brown wrote:
> >In the end I did this to quiet /etc/security on my systems:
> >...
> >+               shells["/sbin/nologin"]++;
> >+               shells["/usr/games/wargames"]++;
> >+               shells["/usr/libexec/uucp/uucico"]++;
> >...
> >I think that's a little cleaner than your patch, though definition of a
> >companion file such as /etc/shells.nonstd might be even better (I
> >usually prefer data-driven programs to modifying hard-coded data within
> >a program, but I was too lazy to go that far with my own local source tree).
> 
> this sounds reasonable, but, iirc, will later cause accounts that have
> no password to be declared "inactive but with a valid shell".
> 
> a better fix might be to specifically allow /sbin/nologin as a shell
> at the point that emits the complaint in question.

That's what my diff does (although it's reverted, hum), but it a) hardcodes
/sbin/nologin (don't think that this will change, but ...) and b) is not quite
flexible. Greg A Woods reply shows, too, that it's not only nologin to take
care of. So, add an column to /etc/shells to mark 'pseudo' shells ? Or a mark
in the path ? Or add a list of common pseudo shells to the /etc/security, like,
establish

alt_shells["/sbin/nologin"]++;
alt_shells["/usr/games/wargames"]++;
alt_shells[Whateverelse]++;...

and check at the specific place

else if (! shells[$10] && !alt_shells[$10] )
instead of my suggestion ?

Well, just some thoughts down the drain,

-Martin