rust: Add a composefs-oci crate

[cgwalters]

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.

• I think relying on zstd:chunked and especially the part about indexing objects by their sha256 is wrong. We should index by the fsverity digest - especially in a time when people want to store potentially multi-GB files in container images, computing a checksum in two different ways is quite suboptimal. Note that using a new C API exposed by this project, if the filesystem doesn't physically support fsverity, we just compute it in userspace.
• The repo also tracks whether fsverity was supported at init time and can be configured to hard require it. By tracking enablement we can also support a "migrate repo to enabling fsverity" for e.g. XFS when it gains that support.
• Related to the above on the bootc side we definitely want file sharing between images; this will lead to a need for GC handling (xref https://github.com/containers/composefs/issues/125 )
• There's a logistical issue in Go vs Rust going on here...we can bridge it of course, but:
• Managing file paths in userspace makes me nervous; there's lots of subtleties. This design sketch hard requires and uses openat2 for unpacking, ensuring the kernel handles things like canonicalization of // etc. and symlink traversal.

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.

[alexlarsson]

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"?

[cgwalters]

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.