Subject: Re: CVS commit: src/etc
To: Hubert Feyrer <hubert@feyrer.de>
From: Luke Mewburn <lukem@NetBSD.org>
List: tech-userlevel
Date: 04/07/2005 10:17:30
--9RxwyT9MtfFuvYYZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
  |=20
  | Thanks for speaking up as core@.
  |=20
  | Can you please outline what the rationale is, and about what other=20
  | "system" users it is? Questions I see here are:
  |=20
  |  * 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
existing accounts.



Luke.

(Speaking personally, providing background on the core decision).

--9RxwyT9MtfFuvYYZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFCVHwapBhtmn8zJHIRAs7UAJ91HqGc4v0kSA+p4D/EvSYYFSRXJgCeLmp1
+BqRIGGc5no/9iAZelsugzg=
=/FoV
-----END PGP SIGNATURE-----

--9RxwyT9MtfFuvYYZ--