On Wed, 30 Dec 1998, Hubert Feyrer wrote:

> 1. Every package should care to create the accounts it needs.
>    We don't carry stuff for pkgs not installed around either - 
>    /usr/pkg is empty on new systems (if it exists at all). Any
>    account flying around unused is just a potential security hole.

The problem with this is IDs. If the account is already there, you
can fit it into NetBSD's `standard' scheme for account IDs; if it's
not, you either run the risk of overwriting an ID that someone's
created, or end up creating a different UID number on every system,
which makes life inconvenient, at best, in installations with
multiple machines. How do you deal with a shared install of MySQL
where it's on one central server shared via NFS, but the password
files on all the machines are different, for example?

> 2. There should be no "general" accounts. 
>    This makes it possible to distribute administration of things
>    among several people, with each protected against the others.
>    This is also a security issue - imagine a system with several
>    database systems installed needs just one of them hacked some
>    way, and _all_ databases can be accessed. 

Sure, but relatively few systems have several databases installed,
and only a fraction of those are going to worry about splitting
them all up under separate IDs. (I'm relatively paranoid compared
to most admins I've known, and I wouldn't do this.) I think this
situation is more easily handled by letting the few admins in this
situation compile from source and deal with things that way.

> > (Adding new users with pkg_add is problamatic, at best.)
> 
> I don't think so. Not too.

Perhaps you can explain how to deal with the multiple-UID/shared
binaries situation, then.

cjs
--
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org