Date: Mon, 30 Nov 2015 18:31:07 -0800 From: Tim Kientzle <tim@kientzle.com> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Michal Ratajsky <michal.ratajsky@gmail.com>, Brooks Davis <brooks@freebsd.org>, "Simon J. Gerraty" <sjg@juniper.net> Subject: Re: mtree "language" enhancements Message-ID: <71D3DCA2-B336-4849-88E3-8412F8A93324@kientzle.com> In-Reply-To: <CANCZdfo3fsupKZ3TJ%2B8MBhXR27c9dHkCYVa7R6J2q-z2mdAGmA@mail.gmail.com> References: <CANCZdfrDtfkwKxMV3o9tcQNzBQDKZdTx1JErkTKtC7UZORT5aA@mail.gmail.com> <AFF9BC5D-536B-4F7D-83CC-E26D9CBA8BF3@kientzle.com> <CANCZdfp%2BtCnXDkbMan9crp9YepVnZKT_hSw%2Bi43OAzZX3VWhXg@mail.gmail.com> <A5A83D40-6B19-465C-9042-3DB3FB127759@kientzle.com> <0A51B6D4-9EDD-4EFF-876F-C6B515DBB4F3@kientzle.com> <CANCZdfo3fsupKZ3TJ%2B8MBhXR27c9dHkCYVa7R6J2q-z2mdAGmA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Nov 29, 2015, at 9:49 PM, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Sun, Nov 29, 2015 at 9:28 PM, Tim Kientzle <tim@kientzle.com> = wrote: >=20 >>=20 >>> On Nov 29, 2015, at 2:49 PM, Tim Kientzle <tim@kientzle.com> wrote: >>>=20 >>> Simon also asked: >>>> Indeed I'd really like the ability to provide default uid/gid >>>> for the case that a uname/gname cannot be looked up. >>>=20 >>> I think 'tar' got this right: If uname and uid are both specified, = then >> look up uname and if that fails, use the specified uid. Ditto for >> gname/gid. In particular, this lets a single specification be used = to >> rebuild a tree on another system with different UIDs or on a system = that >> does not (yet) have a full password file. An option could be = provided for >> the (rare) case that someone really wants to prefer UIDs to unames. >>=20 >> On further reflection, preferring UIDs to unames would actually be = pretty >> common here. >>=20 >> In particular, NanoBSD (and Crochet and other similar tools) should = prefer >> the UID when building images instead of looking up unames against the = build >> host's password file. >=20 >=20 > I've implemented what we've talked about, except this. When doing the > makefs, we should use the /etc/master_password that's inside the image = in > preference to either of these alternatives. That's the most correct = thing > to do: use as much of the data as you can, as late as you can. >=20 > The thing I'm struggling with now is why would both be present? Would = that > indicate an error? Or someone changing the defaults? And if they are > changing the defaults, why use a uid in preference to a uname? Is this = to > avoid contamination? To set something not in the password file, or = just > comfort level of the user? FreeBSD will write unames for install*. >=20 > So I'm left thinking that maybe the rule should be 'last one wins' at = least > for the use case where we use the target's /etc/master_password. = That's > what I've actually implemented. There are two key cases that drove this design for tar: 1. Handling user info that is not (yet) in the target password file. = In practice, images get built up in different orders: I might add a = bunch of new files owned by a new user before some other process gets a = chance to add the user. 2. Restoring info when the target has different user numbering than the = host. (Or when the user isn=E2=80=99t in the host password file at = all.) For #1, you need the UID since the uname can=E2=80=99t be looked up = anywhere. For #2, you must have the uname since the UID would be wrong. = An image that can work in either scenario needs to have both. For NanoBSD, you may be able to enforce that users are always present in = the target password file before any data owned by those users is added = to the image. So it may be reasonable to just rely on uname everywhere = for now. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71D3DCA2-B336-4849-88E3-8412F8A93324>