[ On Sunday, March 14, 1999 at 14:13:07 (-0800), David Brownlee wrote: ]
> Subject: Unnecessary standard accounts (Was: Root, toor accounts.)
>
> 	Most of the packages seem to use addnerd to create accounts
> 	as needed. Maybe some of the package people could comment?

In general I agree that it should be up to the package to add accounts
as needed, though there is a potential issue w.r.t. consistency between
systems when this approach is chosen, especially when NFS is used
between such systems.

I also think addnerd is still pretty well useless for creating "system"
accounts.  It's excellent for what it does and I'm glad it's available,
but it is far from being the most complete solution to the problem (and
of course it doesn't claim to be a complete solution either).

Take a look at FreeBSD's "pw" tool for something more appropriate (and
more standard, I think).  For a real-life example look at the FreeBSD
cyrus IMAP "port"'s install script to see how "pw" is much more useful
for creating system accounts:

    ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/ports/mail/cyrus/pkg/INSTALL

Of course that script isn't quite as smart as it could be.  For instance
it could use 'pw -u 10,100' to restrict the user-id to be in what's
often thought of as the range for "system" accounts instead of trying to
hard-code it to a fixed value.

BTW, I'd love to see NetBSD import FreeBSD's "pw" ASAP.

HISTORY
     Pw was written to mimic many of the options used in the SYSV shadow sup-
     port suite, but is modified for passwd and group fields specific to the
     4.4BSD operating system, and combines all of the major elements into a
     single command.

It should be relatively easy to write a wrapper script around pw that's
truly compatible with SysV's passmgmt too (if not to implement it
directly in the internal command-line handling).

> 	b) Switch its default shell to /sbin/nologin to quiet security.

Sounds OK, though I usually turn off the "is off but still has a valid
shell" check because I can't find any validity in such a warning.  It
might make more sense if it warned "is off and has an *invalid* shell"
because then root might trip over something nasty if su'ing without
'-m'.  I find it much more natural to make someone's password invalid
than I do to change their shell if I want to disable their account, and
without a valid password it's irrelevant what their shell is (except
from root's perspective, which is why I think it should only report
*invalid* shells on disabled accounts).

Of course I also disable the "does not have a valid shell" check too
because one often wants to specifically assign a user a shell that's
purposefully not listed in /etc/shells -- that's one of its purposes and
should not be considered an exception worth reporting by /etc/security!

Maybe this confusion wouldn't be so prevalent if shells(5) was uptdated
with relavent text from chsh(8) and ftpd(8).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>