Subject: Re: admin/15698: /etc/security vs. /etc/shells in regard to /sbin/nologin
To: NetBSD GNATS submissions and followups <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 02/24/2002 20:36:21
>> >> this sounds reasonable, but, iirc, will later cause accounts that have
>> >> no password to be declared "inactive but with a valid shell".
>> >Yes, of course -- that's the desired behaviour. If you don't want
>> >some/all of those reported then that's a different issue.
>> eliminating one "erroneous" message so that one gets three more is
>> most certainly not the point.
>These are TOTALLY SEPARATE ISSUES!!!!!
no, they're not. if you want to change something to eliminate one
message and that causes three more (or more) to pop out, that means
they're related. besides, this all falls under the topic of
>> accounts that currently have * as the
>> password and /sbin/nologin as the shell should not cause any message
>> from /etc/security.
>Well now that depends on what a given site's security policy says, now
ultimately, yes, but since netbsd ships nine "users" in the default
master.passwd file that have * as the password and /sbin/nologin as
the shell, i think it's say to say that getting no warnings about
those accounts is en expected behavior.
>In the "normal" case such accounts are abberations and should be
>reported by /etc/security.
in the normal case, such accounts are system accounts, and should not
be reported by /etc/security. i don't think i've *ever* seen a unix
system that didn't have at least one "system" account, and system
accounts shouldn't cause nightly warnings.
>If on your system the locked accounts (and of course '*' is only a
>semi-common convention, not the only way to lock an account -- my own
>/etc/security recognizes all possible means of locking accounts) are
>"normal" then perhaps you'd like to have a bit more dynamic runtime
>control over the checks done by /etc/security and how they are reported.
on my systems, i have several varieties of accounts.
(1) system accounts, with * and /sbin/nologin
(2) accounts with passwords and ssh keys (me)
(3) accounts with passwords that ftp only
(4) accounts with ssh keys only (can't log in via ftp or pop, etc)
(5) accounts with only passwords (root)
for the type 4 account, where they user has no password, i usually put
the string "ActiveAccount" instead of a *, since /etc/security likes
that, and it means something to me. i realize you probably have a
>> >> a better fix might be to specifically allow /sbin/nologin as a shell
>> >> at the point that emits the complaint in question.
>> >No, I don't think so. At least with adding the shells explicitly to the
>> >list in the array you don't have to mess with an ever more complex
>> >expression in the logic of the program.....
>> # diff /etc/security /usr/src/etc/security
>> < } else if (! shells[$10] && $10 != "/sbin/nologin")
>> > } else if (! shells[$10])
>Thank you for re-inforcing my point again for me!
that's hardly complex. and as i said before, adding the shells you
listed to the list of valid shells creates more trouble than it's
creating a list of "invalid but permissable" shells (like
/sbin/nologin) may have some utility...
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."