Date: Thu, 3 Dec 2015 18:58:32 +0900 From: Masao Uebayashi <uebayasi@gmail.com> To: Tim Kientzle <tim@kientzle.com> Cc: Warner Losh <imp@bsdimp.com>, "Simon J. Gerraty" <sjg@juniper.net>, Michal Ratajsky <michal.ratajsky@gmail.com>, Brooks Davis <brooks@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: mtree "language" enhancements Message-ID: <CADbF7efeRDbL0D7stL30q-GjX_xXiBoSHtxF_ZGp1e6auwnrRA@mail.gmail.com> In-Reply-To: <71D3DCA2-B336-4849-88E3-8412F8A93324@kientzle.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> <71D3DCA2-B336-4849-88E3-8412F8A93324@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 1, 2015 at 11:31 AM, Tim Kientzle <tim@kientzle.com> wrote: > >> On Nov 29, 2015, at 9:49 PM, Warner Losh <imp@bsdimp.com> wrote: >> >> On Sun, Nov 29, 2015 at 9:28 PM, Tim Kientzle <tim@kientzle.com> wrote: >> >>> >>>> On Nov 29, 2015, at 2:49 PM, Tim Kientzle <tim@kientzle.com> wrote: >>>> >>>> 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. >>>> >>>> I think 'tar' got this right: If uname and uid are both specified, th= en >>> 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 tha= t >>> 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. >>> >>> On further reflection, preferring UIDs to unames would actually be pret= ty >>> common here. >>> >>> In particular, NanoBSD (and Crochet and other similar tools) should pre= fer >>> the UID when building images instead of looking up unames against the b= uild >>> host's password file. >> >> >> 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 i= n >> preference to either of these alternatives. That's the most correct thin= g >> to do: use as much of the data as you can, as late as you can. >> >> The thing I'm struggling with now is why would both be present? Would th= at >> 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 t= o >> avoid contamination? To set something not in the password file, or just >> comfort level of the user? FreeBSD will write unames for install*. >> >> So I'm left thinking that maybe the rule should be 'last one wins' at le= ast >> 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 a= dd the user. When you say "image", you surely mean "file-system image". File-system image contains on-disk data (inode), which contains UID/GID instead of symbolic ones (uname/gname). When you decide to create an image, you have a whole tree (directories/files) that ends up in a generated file-system image. Which means that when you create an image, you must know all the files and UIDs/GIDs put there. If not, what you are creating should not be an image. If you don't know UIDs/GIDs, can't you just create a tar archive, and extract it when you really create an image later? I don't really want mtree(1) unnecessarily smart so it makes unnecessary decisions. I want it to be simple and deterministic. > 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 anywh= ere. For #2, you must have the uname since the UID would be wrong. An ima= ge 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 t= he image. So it may be reasonable to just rely on uname everywhere for now= . > > Tim > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADbF7efeRDbL0D7stL30q-GjX_xXiBoSHtxF_ZGp1e6auwnrRA>