Subject: Re: admin/15698: /etc/security vs. /etc/shells in regard to /sbin/nologin
To: Andrew Brown <firstname.lastname@example.org>
From: Martin Weber <Ephaeton@gmx.net>
Date: 02/23/2002 02:24:21
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,
and check at the specific place
else if (! shells[$10] && !alt_shells[$10] )
instead of my suggestion ?
Well, just some thoughts down the drain,