Subject: Re: CVS commit: src/etc
To: Hubert Feyrer <email@example.com>
From: Luke Mewburn <lukem@NetBSD.org>
Date: 04/07/2005 10:17:30
Content-Type: text/plain; charset=us-ascii
On Thu, Apr 07, 2005 at 02:00:13AM +0200, Hubert Feyrer wrote:
| On Thu, 7 Apr 2005, Luke Mewburn wrote:
| >Peter asked core about this. Core approved it, based on similar
| >rationale for the decision core made about new "system" users.
| Thanks for speaking up as core@.
| Can you please outline what the rationale is, and about what other=20
| "system" users it is? Questions I see here are:
| * should future imports of this kind keep the original ("_", etc.)
| username, to give up consiscency in NetBSD over keep differences with
| other systems small?
Generally, yes, although we'd need to consider any deviations away
from our new general policy of
``namespace protecting per service user (and group) names
with a leading `_' to prevent nameclashes with user accounts
on end user systems.''
| * should all "system" accounts be renamed to have a leading "_"?
Yes, for the appropriate system accounts (not necessary `all "system"
accounts'). These would include accounts we've added recently
for specific services (sshd, smmsp, ntpd, named) except where that
would break the common usage for that service and it makes sense.
We need to consider the migration plan for these accounts.
Some proposals have been suggested:
* Update postinstall to warn about this.
However, not fix, for the same reason we don't for
the existing uid/gid checks: the user accounts
may actually be in a separate (nsswitch) passwd
database than /etc/master.passwd.
postinstall could be updated to try getent, but
that could only work for 'native' invocations,
not cross or destdir invocations.
* Add replicate entries for the accounts we're renaming,
leaving the old account and the new one, at least
for a release.
That will cause /etc/security to complain.
Because of the complexity of the migration decision, core decided
to keep separate the operations of changing the per-service username
policy and using that for pflogd from the operation of renaming
(Speaking personally, providing background on the core decision).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----