mtree "language" enhancements

[Masao Uebayashi]

On Tue, Dec 1, 2015 at 11:31 AM, Tim Kientzle <tim at kientzle.com> wrote:
>
>> On Nov 29, 2015, at 9:49 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>> On Sun, Nov 29, 2015 at 9:28 PM, Tim Kientzle <tim at kientzle.com> wrote:
>>
>>>
>>>> On Nov 29, 2015, at 2:49 PM, Tim Kientzle <tim at 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, 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.
>>>
>>> On further reflection, preferring UIDs to unames would actually be pretty
>>> common here.
>>>
>>> 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.
>>
>>
>> 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.
>>
>> 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*.
>>
>> 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.

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’t in the host password file at all.)
>
> For #1, you need the UID since the uname can’t 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
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"