In some mail I received from Luke Mewburn, sie wrote
> 
> 1. Remote access for root with empty password
> ---------------------------------------------
[...]
> The submitter (David Sharnoff) still wants the functionality of prevented
> root access if root's password is empty. I don't believe that this is
> a special case that we need to support in r{sh,login} or ftp.

Some of us like not having to put in a root password on our own isolated
networks :-)

> 2. su(1) uses /etc/group instead of current grouplist
> -----------------------------------------------------
> 
> PRs 792 and 2466 both mention that su(1) parses /etc/group for the
> contents of gid 0 to determine if access is permitted to root.
> If a user's primary group is 0, but they're not in /etc/groups, things
> fail.
> 
> The suggested solution is to check the users' *current* group list
> using getgroups() (both primary & supplimentary groups) for
> existance of gid 0, instead of getpwent(getuid()) and getgrgid(0).
> This is consistant with other access checks on the system...

I consider /etc/group & wheel to be an "access control" mechanism for
su'ing to root (as opposed to being gid 0).  In many modern unixes,
gid "0" means nothing special (except that it is wheel/root and used
by su when consulting /etc/group).  Gid 0 set in /etc/passwd should not
render /etc/group obselete.

> 3. su(1) ignores expired password or account
> --------------------------------------------
> 
> PR 935 adds support to su(1) to notify of impending password or
> account expiry, and to prevent non-root su to expired accounts.
> 
> login(1) enforces this, and I believe the solution is sound.
> 
> However, I would also add a general #define in <pwd.h> for
> "WARNDAYS" so that login(1), su(1) and any other related programs,
> consistantly use the same grace period.
> 
> 
> 4. login(1) patch to force password change on initial login
> -----------------------------------------------------------
> 
> PR 936 adds support for a "magic" password change date to force users
> to change their passwords on initial login.
> 
> This is good. I'd also add support to su(1) for this, and ensure that
> the value for the "magic" change is
>     a) in <pwd.h>
>     b) documented in passwd(1), passwd(5), and elsewhere

How do we communicate this requirement to people logging in via ftp ?
(both for 3 & 4).  What about for ssh ?  rsh (i.e. starting xterms) ?

> 5. packet dump support in tcpdump(8)
> ------------------------------------
> 
> PR 1205 adds hex/ascii packet dumping to tcpdump(8), and telnet option
> parsing.
> 
> cgd commented that this has been brought up in the past and knocked down.
> 
> However, Solaris' snoop(1) allows this. Given that tcpdump(8) can only
> be run by root, it woudl be trivial to supply an application that can
> do this anyway. I can't see the problem with this, but this is a
> controversial issue...

I think it would be better to write a different program to do this, maybe
even a "snoop" for NetBSD.  Reason is that tcpdump originates outside of
NetBSD and changes to it are not likely to care for what we do.  If there
was strong support of making tcpdump do it, there should be feedback to
the group at LBL so that they get the same code (and aren't doing something
like that themselves).

btw, one of my main hacks to tcpdump is to add ascii packet dumps (it
already supports hex dumps: tcpdump -x).

> 6. inetd runs before securelevel is raised
> ------------------------------------------
> 
> PR 1323 highlights that inetd(8) and other programs are run from
> /etc/rc before securelevel is raised. Therefore, it is possible for
> users to get into a system before securelevel is raised.
> 
> This is a complicated issue, and probably deserves its own thread.
> No idea on how to solve it.

How about adding a loop to inetd that checks if the securelevel is 0
and if so, waits until it becomes > 0 ?  This is based on the theory
that securelevel is only 0 during booting and the eventual multiuser
value for securelevel > 0 whilst allowing it to start if secureleve is -1.

> 7. log root login failures at a different log level
> ---------------------------------------------------
> 
> PR 2075 changes things so that root login failures are at LOG_WARNING
> instead of LOG_NOTICE.
> 
> I'm not sure if this is totally necessary, but I'm neutral either
> way... Comments?

My feeling would be to look at where syslog sends LOG_NOTICE in default
syslog.conf and/or check how much other noise is generated at LOG_NOTICE
compared to LOG_WARNING.

Darren