Closed cgwalters closed 2 weeks ago
What I want to do next here is teach mkcomposefs to optionally honor a user.cfs.meta xattr. This way we can unpack a tarball to disk, but instead of e.g. physically setting sensitive file metadata like owner uid, gid, suid bits, and security-related xattrs, we can do something much like what ostree's bare-user mode does and store them in an xattr. We can also skip making specials like device nodes and FIFOs "physically" and just make a zero-sized regular file with the xattr.
I'm not sure I understand why you want this? During the import, can't you just compute the dump-format file line by line in combination with the object files and pass that to mkcomposefs? Why do you need the file metadata "on-disk"?
For now I think it makes sense actually to keep this repository with just "core" functionality. I have created https://github.com/cgwalters/composefs-oci as an experimental place to iterate.
The high level goal of this crate is to be an opinionated generic storage layer using composefs, with direct support for OCI. Note not just OCI containers but also including OCI artifacts too.
This crate could to be the successor to the "storage core" of both ostree and containers/storage.
This is an initial sketch! It'd be good to sync on the design/goals; it started to "feel" right but obviously there's a whole lot going on. In particular, when I was going through the current containers/storage composefs code...there's a few things here where I am not sure it has the right architecture.
//
etc. and symlink traversal.What I want to do next here is teach
mkcomposefs
to optionally honor auser.cfs.meta
xattr. This way we can unpack a tarball to disk, but instead of e.g. physically setting sensitive file metadata like owner uid, gid, suid bits, and security-related xattrs, we can do something much like what ostree'sbare-user
mode does and store them in an xattr. We can also skip making specials like device nodes and FIFOs "physically" and just make a zero-sized regular file with the xattr.