L A Walsh wrote:
Re meta data source.
Maybe I'm not expressing my concern clearly or maybe a different
definition of metadata is being used? Strictly speaking, I consider
meta data to be any data that is NOT the data in a file (or directory)
and would normally include ownership, permissions and extended attributes.
From an ease-of-access and implementation point of view, some may not
consider information in the inode, strictly, 'metadata', but the line
becomes blurry when file access information is stored not only in the
inode, but also in the, potentially separate, extended attribute area(s)
of a file system, for example, AFAIK, AC lists are stored in extended
attributes with some file system implementations -- especially if they
are longer (or larger) lists.
It seems that access information would have to be read from the lower
file system (and, implicitly, meta data) or would otherwise be
unavailable or ignored. Certainly an overlay can't ignore the
security information contained in the metadata in the lower layers and
would have to, it seems, inspect the metadata associated with an inode
if for no other reason to read ACL and/or fscap's set in the lower
filesystem.
I don't see any mention of how setuid/setgid bits are set, but one would
assume that if such are supported, then FS-based capabilities would
also need to be read from the lower filesystem.
It _may_ not be necessary, but it seems prudent, that the upper level
file system would (or should?) have the same "features" as the lower
file system so a merged-view would be consistent with the isolated view
of the lower filesystem, no? It seems it would be problematic if the
upper filesystem didn't support the same features as the lower.
Could it be clarified if the overlayfs ignores lower FS metadata like
ACL's and set-capability info?
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
