On Mon, Jun 12, 2023 at 7:32 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Mon, Jun 12, 2023 at 12:27:17PM +0200, Alexander Larsson wrote: > > +fs-verity support > > +---------------------- > > + > > +When metadata copy up is used for a file, then the xattr > > +"trusted.overlay.verity" may be set on the metacopy file. This > > +specifies the expected fs-verity digest of the lowerdata file. This > > +may then be used to verify the content of the source file at the time > > +the file is opened. During metacopy copy up overlayfs can also set > > +this xattr. > > + > > +This is controlled by the "verity" mount option, which supports > > +these values: > > + > > +- "off": > > + The verity xattr is never used. This is the default if verity > > + option is not specified. > > +- "on": > > + Whenever a metacopy files specifies an expected digest, the > > + corresponding data file must match the specified digest. > > + When generating a metacopy file the verity xattr will be set > > + from the source file fs-verity digest (if it has one). > > +- "require": > > + Same as "on", but additionally all metacopy files must specify a > > + verity xattr. This means metadata copy up will only be used if > > + the data file has fs-verity enabled, otherwise a full copy-up is > > + used. > > It looks like my request for improved documentation was not taken, which is > unfortunate and makes this patchset difficult to review. > Which one? IIRC, you had two requests. One very broad to get the overlayfs.rst document up-to-date: [1] https://lore.kernel.org/linux-unionfs/20230514190903.GC9528@sol.localdomain/ But I assume you mean the specific request about this sentence: [2] https://lore.kernel.org/linux-unionfs/20230514192227.GE9528@sol.localdomain/ I must say, I re-read this paragraph and the email thread and I don't understand what it is that you are asking for. I am not trying to dismiss your request, I am trying to understand. I understand that overlayfs.rst is not a high standard spec and that "metacopy files" is not well defined and I am not saying that we cannot improve the documentation. But since you already spent the extra time understanding the inaccuracies of overlayfs.rst during v2 review and we already tried to explain the details of metacopy in v2 review, please elaborate what information is actually missing that made the review of v3 harder for you, so that we can try to improve those parts. Let me try to tell this story in a different way Imagine a feature: send/recv email attachments by reference instead of attaching files, drop them in a network share and send/recv a URL to that share with optional verity sig. verity=off: do not include verity sig when sending emails do not verify verity sig when receiving emails verity=on: include verity sig when sending emails (if available) verify verity sig if it is included in received email verity=require: same as verity=on, but if verity sig is not included in received email, do not follow URL. if verity sig not available when sending, attach the file itself instead of the URL - that is what "otherwise a full copy-up" means in the context above To me this sounds exactly like the documentation above. Is this story clear? If it is, what in the doc above is missing to make it also clear? Thanks, Amir.
