Date: Sun, 29 Nov 2015 11:58:48 -0700 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: mtree "language" enhancements Message-ID: <CANCZdfrJt3aGEwzAoe7q%2B-WvVLD5Wv_342uAyKAAhvjicFeQ5w@mail.gmail.com> In-Reply-To: <44936.1448820967@critter.freebsd.dk> References: <CANCZdfrDtfkwKxMV3o9tcQNzBQDKZdTx1JErkTKtC7UZORT5aA@mail.gmail.com> <44936.1448820967@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 29, 2015 at 11:16 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message < > CANCZdfrDtfkwKxMV3o9tcQNzBQDKZdTx1JErkTKtC7UZORT5aA@mail.gmail.com> > , Warner Losh writes: > > >As part of making NanoBSD buildable by non-root, I've found a need to have > >a richer mtree language than we currently have. > > >I'd like a new type called 'action' (so type=action in the records). This > >type is defined loosely to manipulate and earlier entry (or maybe entries, > >still unsure) in the file. > > I suggest you define this so that all records have an action, and that > the default action is "create" >From a practical point of view, I didn't consider this, but that is what would be a logical consequence of these extensions. > > >2. "move" which relocates a previous entry. An additional targetpath > >keyword specifies the ultimate destination for this entry. > >3. "copy" which duplicates a previous entry. It too takes targetpath. > > Is targetpath absolute or relative ? > relative to top of tree. > Can it reach out of the mtree root ? Nope. Those cases need entirely new entries. > > >4. "meta" which changes the meta data of the previous entry. All keywords > >on this are merged with the previous entry. > > System-III called this "chmog" if I recall correctly :-) I love that term. I'll steal it :) > > >The one other thing that my merging tool does is to remove all size > >keywords. > > That sounds wrong to me. Shouldn't you just emit "meta" records updating > the size as appropriate ? > Emitting records that change the size is possible, but would add an extra step. It's easy to catch mv, rm, etc, but hard to catch >>. I took the easy way out of just ignoring size changes, though one could add a nano_resize <path> command that you need to call after changing the size of a file in the post-processing phase. > What about digest fields ? > In my use case, they are irrelevant. They aren't generated by buildworld's metalog, and aren't generally useful. They might add some protection against tampering between when the tree is created and when it is put into a partition, but that's racy. For an attacker, if they can replace the file after it is created but before the checksum is run, they win. So there's little value here for me. However, having said that, digest fields either should be discarded (for the same reason as size), or they should be correct before the dedup tool / enhanced mtree gets to them. This gets into the nuts and bolts of NanoBSD: we copy files around all the time, but have no spec for them. The usual answer is to have a bunch of chmod / chown calls that 'fix' them up and generate a mtree for the image so you can protect against corruption in the field (or at least know what changed). In a nopriv-build, you need to somehow record these changes. Do I continue the traditional behavior, or do I require a new mtree spec for all the files you wish top copy and use that to modify the metalog, or hack the permissions directly for the priv-build case. The decision between discard and check likely is an input to the dedup tool. For NanoBSD the decision is likely to default to discard. But other tools might want to check, and some NanoBSD users may wish to climb the hill to being correct by adding calls to correct the size everywhere. My first goal is to create a tool that produces correct images with the right permissions. A secondary goal would be to safe-guard the process from unintended changes that would be caught by size and/or digest changes. It isn't a current feature of NanoBSD, but that doesn't make it undesirable. Especially if your NanoBSD build process puts precious files onto the media that you want to make sure the rest of the build process doesn't tamper with accidentally to guard against bugs... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrJt3aGEwzAoe7q%2B-WvVLD5Wv_342uAyKAAhvjicFeQ5w>