-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What if char devices are being used as regular files? #2568
Comments
Hi, this is related to ostreedev/ostree-rs-ext#246 I see the desire to simply ship podman's storage, but trying to change ostree to accept character devices at this time would be a large change. In the end, inherently the "ostree nature" of e.g. not shipping timestamps will also leak through into the containers, so it's really better for us to handle it by flattening I think. |
First, it makes no sense to ship device nodes in OS images (ostree commits, containers, disk images) in my opinion. These things represent dynamic state - container runtimes and systemd will ensure that Also because container runtimes do that, you have to go to effort to get content in There's two paths:
|
We hit another case where people are pulling a container image with devices in `/dev` in the tar stream; they're then trying to commit this to an ostree. There's much better ways to fix this: - Change the image to stop including devices as there's no reason to do so - Switch to logically bound images instead of physically bound - Use the composefs backend for c/storage Eventually I may look at "quoting" generally in ostree, but it's fairly invasive: ostreedev/ostree#2568 In practice today, simply ignoring the files will happen to work for "podman run" of such images; podman will just use overlayfs to stitch together the `diff` directories, and doesn't try to do any validation of their contents today. (Queue the composefs integration, which *would* do that but would also fix this anwyays)
OK I looked at this briefly but it touches some of the most complex and hairy code in ostree...the
|
Put up a bit more of a draft in #3318 but again - nontrivial and invasive and basically: Don't put devices in your images, it makes no sense. |
We hit another case where people are pulling a container image with devices in `/dev` in the tar stream; they're then trying to commit this to an ostree. There's much better ways to fix this: - Change the image to stop including devices as there's no reason to do so - Switch to logically bound images instead of physically bound - Use the composefs backend for c/storage Eventually I may look at "quoting" generally in ostree, but it's fairly invasive: ostreedev/ostree#2568 In practice today, simply ignoring the files will happen to work for "podman run" of such images; podman will just use overlayfs to stitch together the `diff` directories, and doesn't try to do any validation of their contents today. (Queue the composefs integration, which *would* do that but would also fix this anwyays) Signed-off-by: Colin Walters <[email protected]>
We hit another case where people are pulling a container image with devices in `/dev` in the tar stream; they're then trying to commit this to an ostree. There's much better ways to fix this: - Change the image to stop including devices as there's no reason to do so - Switch to logically bound images instead of physically bound - Use the composefs backend for c/storage Eventually I may look at "quoting" generally in ostree, but it's fairly invasive: ostreedev/ostree#2568 In practice today, simply ignoring the files will happen to work for "podman run" of such images; podman will just use overlayfs to stitch together the `diff` directories, and doesn't try to do any validation of their contents today. (Queue the composefs integration, which *would* do that but would also fix this anwyays) Signed-off-by: Colin Walters <[email protected]>
We hit another case where people are pulling a container image with devices in `/dev` in the tar stream; they're then trying to commit this to an ostree. There's much better ways to fix this: - Change the image to stop including devices as there's no reason to do so - Switch to logically bound images instead of physically bound - Use the composefs backend for c/storage Eventually I may look at "quoting" generally in ostree, but it's fairly invasive: ostreedev/ostree#2568 In practice today, simply ignoring the files will happen to work for "podman run" of such images; podman will just use overlayfs to stitch together the `diff` directories, and doesn't try to do any validation of their contents today. (Queue the composefs integration, which *would* do that but would also fix this anwyays) Signed-off-by: Colin Walters <[email protected]>
We hit another case where people are pulling a container image with devices in `/dev` in the tar stream; they're then trying to commit this to an ostree. There's much better ways to fix this: - Change the image to stop including devices as there's no reason to do so - Switch to logically bound images instead of physically bound - Use the composefs backend for c/storage Eventually I may look at "quoting" generally in ostree, but it's fairly invasive: ostreedev/ostree#2568 In practice today, simply ignoring the files will happen to work for "podman run" of such images; podman will just use overlayfs to stitch together the `diff` directories, and doesn't try to do any validation of their contents today. (Queue the composefs integration, which *would* do that but would also fix this anwyays) Signed-off-by: Colin Walters <[email protected]>
I am trying to commit Podman's local storage to OSTree. Now the issue is that Overlayfs uses char devices to represent specific states. From: https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
And now I am stuck because OSTree wants only regular files and links, and trying to commit a tree that contains char devices does not work.
I am trying to convince OSTree that, hey these char devices are actually regular files, because they represent state within the filesystem. But OSTree does not listen to me. Do I have any hope to use OSTree to also commit char devices for cases such as this one?
The text was updated successfully, but these errors were encountered: