Composefs for integrity protection and data sharing

Posted Dec 8, 2022 18:39 UTC (Thu) by hsiangkao (guest, #123981)
In reply to: Composefs for integrity protection and data sharing by gscrivano
Parent article: Composefs for integrity protection and data sharing

> Given a directory with a bunch of files, how do you setup an EROFS mount that contains the metadata for the file system but refers to the files for their actual payload and without requiring the image blob to be transformed to a different format first?
> This is the use case I am interested in.

Why doesn't EROFS work like this? if you consider each EROFS blob as a per-file blob data (currently it's identified by an 16-bit blob ID, but it can extend if you really need like OSTree --- massive per-file blobs), and if each EROFS file has only _one_ chunk pointing to one blob ID.

Does it behave any different? You only change the integer blob ID into a string and strict it with one-file one-chunk.

The only difference is that EROFS uses fscache to manage its cache but that is partially due to our lazy pulling requirement (also I also tend to manage such blobs with a unified in-kernel framework rather than direct access random underlayfs files without some permission check. Take one example in my opinion, one composefs file "/bin/su" but the file was suddenly replaced by a malicious root shell. If fs-verity is disabled, how to prevent this --- on the other side, overlayfs doesn't have this issue since it doesn't keep another permission), you could refer to Incremental FS discussion [1]. Also EROFS already has an in-house version to access files directly for our special uses [2].

> Also let's do a wild guess if composefs finally merges we posted an RFC to gather feedback after we worked on it for quite some time to see if people find it useful but you turned it as if it were an attack on EROFS. It is not.

I just want to say composefs is much much similar to EROFS.

> From the discussion we just had, it seems EROFS still misses page cache sharing and data-integrity check, so it is likely EROFS will grow more as well?

Jingbo Xu is working on page cache sharing for Linux 6.3.
Data-integrity check and encryption for confidential containers will be discussed on the mailing list right after page cache sharing is landed.

[1] https://lore.kernel.org/all/20190502040331.81196-1-ezemts...
[2] https://github.com/alibaba/cloud-kernel/commit/6654d200b4...

Composefs for integrity protection and data sharing

Posted Dec 8, 2022 21:24 UTC (Thu) by gscrivano (subscriber, #74830) [Link] (1 responses)

thanks for the useful information.

> The only difference is that EROFS uses fscache to manage its cache but that is partially due to our lazy pulling requirement

so that is a significant difference. If I understand it correctly we will need to either setup fscache and populate its cache or have a different daemon before we can use this mechanism.

Would it ever be possible to use fscache from a user namespace?

Composefs for integrity protection and data sharing

Posted Dec 9, 2022 2:30 UTC (Fri) by hsiangkao (guest, #123981) [Link]

> so that is a significant difference. If I understand it correctly we will need to either setup fscache and populate its cache or have a different daemon before we can use this mechanism.

Sorry I just went to sleep. Bytedance's folks already developed fscache failover feature and fully daemonless mode for their cloud production, and it's also useful to all network fses. Basically we already developed a lot of features for fscache, it just needs time to upstream.

Overall I just tried to say currently composefs is very similar to EROFS, even it has some difference (such as directly accessing files) it can be adapted without any diffcult.

> Would it ever be possible to use fscache from a user namespace?

I missed this part at that time, sorry. I think EROFS has the same security model as all on-disk fses with on-disk permission model (no matter it's block-based or file-based.) So the question is no different from other on-disk fses, including composefs.