[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] We are looking at using OSTree as a backend for sharing file systems into an OCID Container runtime

On Fri, Oct 14, 2016, at 02:37 PM, Daniel J Walsh wrote:

> If we block the creation of the devices when exploding a OCI Image
> Bundle, we end up with something that is different then what is
> downloaded and this could potentially cause problems with mtree checking
> of the image on disk versus the image as shipped.

would be a good place to discuss this.

> Is there a reason OSTree does not work with Device Inodes? 

Yes, I think there's no good reason to include devices in OS or container
images.  For OS images (i.e. ostree-as-base), all modern systems
use devtmpfs. 

(Also for that matter, a bit more strictly, FIFOs either.
 OSTree very intentionally only supports regular files and

For the Ubuntu Docker image, the user can't even see them
because Docker (correctly) mounts over /dev/ with
the "API devices" as systemd calls them.

So basically...my proposal would be that we
ignore them, and that's indeed what the proposed OSTree
API above does.

If we implement any other verification layer like mtree, it
should then just skip devices and FIFOs (or more generally
anything except regular files and symlinks).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]