Why does Podman update the "Change" timestamp on files shared between host and guest ?
Hi, I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this. According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an... the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)". I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed). Regards Jacob
On 6/28/22 03:15, Jacob Kroon wrote:
Hi,
I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this.
According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an...
the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)".
I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed).
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Could you mount the volume :ro inside of the container and see if the same thing happens? If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container. You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
Hi Daniel, On 6/28/22 16:23, Daniel Walsh wrote:
On 6/28/22 03:15, Jacob Kroon wrote:
Hi,
I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this.
According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an...
the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)".
I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed).
[cut]
Could you mount the volume :ro inside of the container and see if the same thing happens?
Yup, same thing happens even if I mount it with :ro.
If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container.
You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot. Regards Jacob
On 6/28/22 18:48, Jacob Kroon wrote:
Hi Daniel,
On 6/28/22 16:23, Daniel Walsh wrote:
On 6/28/22 03:15, Jacob Kroon wrote:
Hi,
I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this.
According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an...
the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)".
I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed).
[cut]
Could you mount the volume :ro inside of the container and see if the same thing happens?
Yup, same thing happens even if I mount it with :ro.
If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container.
You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot.
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
[pid 2886] lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", "security.selinux", "system_u:object_r:container_file"..., 37, 0 <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument. My host is an up2date Fedora 36. Also, I'm using --userns=keep-id in case that matters. Regards Jacob
On 6/28/22 15:27, Jacob Kroon wrote:
On 6/28/22 18:48, Jacob Kroon wrote:
Hi Daniel,
On 6/28/22 16:23, Daniel Walsh wrote:
On 6/28/22 03:15, Jacob Kroon wrote:
Hi,
I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this.
According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an...
the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)".
I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed).
[cut]
Could you mount the volume :ro inside of the container and see if the same thing happens?
Yup, same thing happens even if I mount it with :ro.
If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container.
You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot.
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
[pid 2886] lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", "security.selinux", "system_u:object_r:container_file"..., 37, 0 <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument.
My host is an up2date Fedora 36.
Also, I'm using --userns=keep-id in case that matters.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
On 6/28/22 22:06, Daniel Walsh wrote:
On 6/28/22 15:27, Jacob Kroon wrote:
On 6/28/22 18:48, Jacob Kroon wrote:
Hi Daniel,
On 6/28/22 16:23, Daniel Walsh wrote:
On 6/28/22 03:15, Jacob Kroon wrote:
Hi,
I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this.
According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an...
the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)".
I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed).
[cut]
Could you mount the volume :ro inside of the container and see if the same thing happens?
Yup, same thing happens even if I mount it with :ro.
If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container.
You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot.
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
[pid 2886] lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", "security.selinux", "system_u:object_r:container_file"..., 37, 0 <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument.
My host is an up2date Fedora 36.
Also, I'm using --userns=keep-id in case that matters.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
Ah yes, I am. To be honest, I haven't fully understood how that flag interacts with the mount point. At some point in time I needed to add it. I have two directories I mount to the guest, one under $HOME (which is the one that is causing me headaches with changed timestamps) and one under /tmp. Unless I use :z on the one in /tmp, I get permission errors when creating files there in the guest. So, I figured I needed :z for the one in $HOME as well. But I see that I can touch files there, even without :z. Does using :z require that "change" timestamps are updated ? Jacob
On 6/28/22 22:26, Jacob Kroon wrote:
On 6/28/22 22:06, Daniel Walsh wrote:
On 6/28/22 15:27, Jacob Kroon wrote:
On 6/28/22 18:48, Jacob Kroon wrote:
Hi Daniel,
On 6/28/22 16:23, Daniel Walsh wrote:
On 6/28/22 03:15, Jacob Kroon wrote:
Hi,
I'm using Podman in my build environment. As part of the build I bind a directory from the host to a directory in the container. Even though the guest doesn't touch the file in any way, afterwards I can see that the file's "Change" timestamp has been updated, so I am assuming it is podman that does this.
According to https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an...
the "Change" timestamp is described as "the last time meta data of the file was changed (e.g. permissions)".
I am wondering what meta data it is that podman changes, and if it can be avoided somehow ? (Mainly because it tricks git/gitk into thinking something might have changed).
[cut]
Could you mount the volume :ro inside of the container and see if the same thing happens?
Yup, same thing happens even if I mount it with :ro.
If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container.
You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot.
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
[pid 2886] lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", "security.selinux", "system_u:object_r:container_file"..., 37, 0 <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument.
My host is an up2date Fedora 36.
Also, I'm using --userns=keep-id in case that matters.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
Ah yes, I am. To be honest, I haven't fully understood how that flag interacts with the mount point. At some point in time I needed to add it.
I have two directories I mount to the guest, one under $HOME (which is the one that is causing me headaches with changed timestamps) and one under /tmp. Unless I use :z on the one in /tmp, I get permission errors when creating files there in the guest. So, I figured I needed :z for the one in $HOME as well. But I see that I can touch files there, even without :z.
Does using :z require that "change" timestamps are updated ?
The manpage for "podman run" states:
The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label.
I'm no SELinux expert, but would it be possible to *not* relabel the files if they already have the correct content label, thus avoiding the "Change" timestamp update ? Regards Jacob
On 6/28/22 16:37, Jacob Kroon wrote:
On 6/28/22 22:26, Jacob Kroon wrote:
On 6/28/22 22:06, Daniel Walsh wrote:
On 6/28/22 15:27, Jacob Kroon wrote:
On 6/28/22 18:48, Jacob Kroon wrote:
Hi Daniel,
On 6/28/22 16:23, Daniel Walsh wrote:
On 6/28/22 03:15, Jacob Kroon wrote: > Hi, > > I'm using Podman in my build environment. As part of the build I > bind a directory from the host to a directory in the container. > Even though the guest doesn't touch the file in any way, > afterwards I can see that the file's "Change" timestamp has been > updated, so I am assuming it is podman that does this. > > According to > https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an... > > the "Change" timestamp is described as "the last time meta data > of the file was changed (e.g. permissions)". > > I am wondering what meta data it is that podman changes, and if > it can be avoided somehow ? (Mainly because it tricks git/gitk > into thinking something might have changed). >
[cut]
Could you mount the volume :ro inside of the container and see if the same thing happens?
Yup, same thing happens even if I mount it with :ro.
If it still happens, then we know it is Podman making the change as opposed to the processes inside of the container.
You could also bind mount the volume readonly on itself, before using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot.
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
[pid 2886] lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", "security.selinux", "system_u:object_r:container_file"..., 37, 0 <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument.
My host is an up2date Fedora 36.
Also, I'm using --userns=keep-id in case that matters.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
Ah yes, I am. To be honest, I haven't fully understood how that flag interacts with the mount point. At some point in time I needed to add it.
I have two directories I mount to the guest, one under $HOME (which is the one that is causing me headaches with changed timestamps) and one under /tmp. Unless I use :z on the one in /tmp, I get permission errors when creating files there in the guest. So, I figured I needed :z for the one in $HOME as well. But I see that I can touch files there, even without :z.
Does using :z require that "change" timestamps are updated ?
The manpage for "podman run" states:
The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label.
I'm no SELinux expert, but would it be possible to *not* relabel the files if they already have the correct content label, thus avoiding the "Change" timestamp update ?
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
The :z causes the labels of the files to have an Sharable label between all containers that will use the directory. If it is always the same directory, then you only need to do it once. Podman is supposed to be smart enough to not do the relabeling after the first time. So either that is a bug, or you do not have a new enough podman. I would drop the :z from the volume mount and it should work fine for you going forward. BTW, you could do $ chcon -t container_file_t -R PATHTOVOLUMESRC And that would do the same as the :z. Then you could use the volumes within the container without the :z. BTW, I am an SELinux expert. :^)
On 6/28/22 22:43, Daniel Walsh wrote:
On 6/28/22 16:37, Jacob Kroon wrote:
On 6/28/22 22:26, Jacob Kroon wrote:
On 6/28/22 22:06, Daniel Walsh wrote:
On 6/28/22 15:27, Jacob Kroon wrote:
On 6/28/22 18:48, Jacob Kroon wrote:
Hi Daniel,
On 6/28/22 16:23, Daniel Walsh wrote: > On 6/28/22 03:15, Jacob Kroon wrote: >> Hi, >> >> I'm using Podman in my build environment. As part of the build I >> bind a directory from the host to a directory in the container. >> Even though the guest doesn't touch the file in any way, >> afterwards I can see that the file's "Change" timestamp has been >> updated, so I am assuming it is podman that does this. >> >> According to >> https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an... >> >> the "Change" timestamp is described as "the last time meta data >> of the file was changed (e.g. permissions)". >> >> I am wondering what meta data it is that podman changes, and if >> it can be avoided somehow ? (Mainly because it tricks git/gitk >> into thinking something might have changed). >>
[cut]
> > Could you mount the volume :ro inside of the container and see if > the same thing happens? >
Yup, same thing happens even if I mount it with :ro.
> If it still happens, then we know it is Podman making the change > as opposed to the processes inside of the container. > > You could also bind mount the volume readonly on itself, before > using podman to see if podman throws an error.
I haven't tried this, let me know if this would be of help and I will give it a shot.
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
[pid 2886] lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", "security.selinux", "system_u:object_r:container_file"..., 37, 0 <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument.
My host is an up2date Fedora 36.
Also, I'm using --userns=keep-id in case that matters.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
Ah yes, I am. To be honest, I haven't fully understood how that flag interacts with the mount point. At some point in time I needed to add it.
I have two directories I mount to the guest, one under $HOME (which is the one that is causing me headaches with changed timestamps) and one under /tmp. Unless I use :z on the one in /tmp, I get permission errors when creating files there in the guest. So, I figured I needed :z for the one in $HOME as well. But I see that I can touch files there, even without :z.
Does using :z require that "change" timestamps are updated ?
The manpage for "podman run" states:
The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label.
I'm no SELinux expert, but would it be possible to *not* relabel the files if they already have the correct content label, thus avoiding the "Change" timestamp update ?
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
The :z causes the labels of the files to have an Sharable label between all containers that will use the directory.
If it is always the same directory, then you only need to do it once. Podman is supposed to be smart enough to not do the relabeling after the first time. So either that is a bug, or you do not have a new enough podman.
I'm using latest podman in Fedora 36, which is v4.1.1. At least to me it would seem that v4.1.1 is not clever enough to avoid messing with the timestamps.
I would drop the :z from the volume mount and it should work fine for you going forward.
BTW, you could do
$ chcon -t container_file_t -R PATHTOVOLUMESRC
And that would do the same as the :z.
Then you could use the volumes within the container without the :z.
BTW, I am an SELinux expert. :^)
I'll take your advice and skip :z for the directory in $HOME. The directory in /tmp is wiped each time I reboot, so I guess it makes sense to keep passing :z there. Thanks for the help! Regards Jacob
On 6/28/22 23:05, Jacob Kroon wrote:
On 6/28/22 22:43, Daniel Walsh wrote:
On 6/28/22 16:37, Jacob Kroon wrote:
On 6/28/22 22:26, Jacob Kroon wrote:
On 6/28/22 22:06, Daniel Walsh wrote:
On 6/28/22 15:27, Jacob Kroon wrote:
On 6/28/22 18:48, Jacob Kroon wrote: > Hi Daniel, > > On 6/28/22 16:23, Daniel Walsh wrote: >> On 6/28/22 03:15, Jacob Kroon wrote: >>> Hi, >>> >>> I'm using Podman in my build environment. As part of the build >>> I bind a directory from the host to a directory in the >>> container. Even though the guest doesn't touch the file in any >>> way, afterwards I can see that the file's "Change" timestamp >>> has been updated, so I am assuming it is podman that does this. >>> >>> According to >>> https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an... >>> >>> the "Change" timestamp is described as "the last time meta data >>> of the file was changed (e.g. permissions)". >>> >>> I am wondering what meta data it is that podman changes, and if >>> it can be avoided somehow ? (Mainly because it tricks git/gitk >>> into thinking something might have changed). >>> > > [cut] > >> >> Could you mount the volume :ro inside of the container and see >> if the same thing happens? >> > > Yup, same thing happens even if I mount it with :ro. > >> If it still happens, then we know it is Podman making the change >> as opposed to the processes inside of the container. >> >> You could also bind mount the volume readonly on itself, before >> using podman to see if podman throws an error. > > I haven't tried this, let me know if this would be of help and I > will give it a shot. >
I ran it through strace and grepped for a dummy file "foobar" that I created and got this:
> [pid 2886] > lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", > "security.selinux", "system_u:object_r:container_file"..., 37, 0 > <unfinished ...>
I'll try to see if I can figure out how to get gdb to break on lsetxattr() with that argument.
My host is an up2date Fedora 36.
Also, I'm using --userns=keep-id in case that matters.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
Ah yes, I am. To be honest, I haven't fully understood how that flag interacts with the mount point. At some point in time I needed to add it.
I have two directories I mount to the guest, one under $HOME (which is the one that is causing me headaches with changed timestamps) and one under /tmp. Unless I use :z on the one in /tmp, I get permission errors when creating files there in the guest. So, I figured I needed :z for the one in $HOME as well. But I see that I can touch files there, even without :z.
Does using :z require that "change" timestamps are updated ?
The manpage for "podman run" states:
The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label.
I'm no SELinux expert, but would it be possible to *not* relabel the files if they already have the correct content label, thus avoiding the "Change" timestamp update ?
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
The :z causes the labels of the files to have an Sharable label between all containers that will use the directory.
If it is always the same directory, then you only need to do it once. Podman is supposed to be smart enough to not do the relabeling after the first time. So either that is a bug, or you do not have a new enough podman.
I'm using latest podman in Fedora 36, which is v4.1.1. At least to me it would seem that v4.1.1 is not clever enough to avoid messing with the timestamps.
I would drop the :z from the volume mount and it should work fine for you going forward.
BTW, you could do
$ chcon -t container_file_t -R PATHTOVOLUMESRC
And that would do the same as the :z.
Then you could use the volumes within the container without the :z.
BTW, I am an SELinux expert. :^)
I'll take your advice and skip :z for the directory in $HOME. The directory in /tmp is wiped each time I reboot, so I guess it makes sense to keep passing :z there.
Thinking about this some more, it would be less work for me as a user if I didn't have to make sure files had the correct SELinux contexts before each podman session. So if podman could be a little more clever when relabeling files because of :z/:Z, that is what I'd prefer. Does that sound like a plausible feature request ? Regards Jacob
On 6/29/22 02:30, Jacob Kroon wrote:
On 6/28/22 23:05, Jacob Kroon wrote:
On 6/28/22 22:43, Daniel Walsh wrote:
On 6/28/22 16:37, Jacob Kroon wrote:
On 6/28/22 22:26, Jacob Kroon wrote:
On 6/28/22 22:06, Daniel Walsh wrote:
On 6/28/22 15:27, Jacob Kroon wrote: > On 6/28/22 18:48, Jacob Kroon wrote: >> Hi Daniel, >> >> On 6/28/22 16:23, Daniel Walsh wrote: >>> On 6/28/22 03:15, Jacob Kroon wrote: >>>> Hi, >>>> >>>> I'm using Podman in my build environment. As part of the >>>> build I bind a directory from the host to a directory in the >>>> container. Even though the guest doesn't touch the file in >>>> any way, afterwards I can see that the file's "Change" >>>> timestamp has been updated, so I am assuming it is podman >>>> that does this. >>>> >>>> According to >>>> https://unix.stackexchange.com/questions/2464/timestamp-modification-time-an... >>>> >>>> the "Change" timestamp is described as "the last time meta >>>> data of the file was changed (e.g. permissions)". >>>> >>>> I am wondering what meta data it is that podman changes, and >>>> if it can be avoided somehow ? (Mainly because it tricks >>>> git/gitk into thinking something might have changed). >>>> >> >> [cut] >> >>> >>> Could you mount the volume :ro inside of the container and see >>> if the same thing happens? >>> >> >> Yup, same thing happens even if I mount it with :ro. >> >>> If it still happens, then we know it is Podman making the >>> change as opposed to the processes inside of the container. >>> >>> You could also bind mount the volume readonly on itself, >>> before using podman to see if podman throws an error. >> >> I haven't tried this, let me know if this would be of help and >> I will give it a shot. >> > > I ran it through strace and grepped for a dummy file "foobar" > that I created and got this: > >> [pid 2886] >> lsetxattr("/home/jkroon/Projects/foobar-linux/foobar", >> "security.selinux", "system_u:object_r:container_file"..., 37, >> 0 <unfinished ...> > > I'll try to see if I can figure out how to get gdb to break on > lsetxattr() with that argument. > > My host is an up2date Fedora 36. > > Also, I'm using --userns=keep-id in case that matters. > > Regards > Jacob > _______________________________________________ > Podman mailing list -- podman@lists.podman.io > To unsubscribe send an email to podman-leave@lists.podman.io
That is SELinux are you mounting with a :Z?
Ah yes, I am. To be honest, I haven't fully understood how that flag interacts with the mount point. At some point in time I needed to add it.
I have two directories I mount to the guest, one under $HOME (which is the one that is causing me headaches with changed timestamps) and one under /tmp. Unless I use :z on the one in /tmp, I get permission errors when creating files there in the guest. So, I figured I needed :z for the one in $HOME as well. But I see that I can touch files there, even without :z.
Does using :z require that "change" timestamps are updated ?
The manpage for "podman run" states:
The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label.
I'm no SELinux expert, but would it be possible to *not* relabel the files if they already have the correct content label, thus avoiding the "Change" timestamp update ?
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
The :z causes the labels of the files to have an Sharable label between all containers that will use the directory.
If it is always the same directory, then you only need to do it once. Podman is supposed to be smart enough to not do the relabeling after the first time. So either that is a bug, or you do not have a new enough podman.
I'm using latest podman in Fedora 36, which is v4.1.1. At least to me it would seem that v4.1.1 is not clever enough to avoid messing with the timestamps.
I would drop the :z from the volume mount and it should work fine for you going forward.
BTW, you could do
$ chcon -t container_file_t -R PATHTOVOLUMESRC
And that would do the same as the :z.
Then you could use the volumes within the container without the :z.
BTW, I am an SELinux expert. :^)
I'll take your advice and skip :z for the directory in $HOME. The directory in /tmp is wiped each time I reboot, so I guess it makes sense to keep passing :z there.
Thinking about this some more, it would be less work for me as a user if I didn't have to make sure files had the correct SELinux contexts before each podman session. So if podman could be a little more clever when relabeling files because of :z/:Z, that is what I'd prefer. Does that sound like a plausible feature request ?
Well yes and no. :z should not be relabeling a second time, and you show up an issue on this. :Z says that the directory should be privately labeled, so in almost no circumstances would the directory be labeled correctly.
Regards Jacob _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
participants (2)
-
Daniel Walsh -
Jacob Kroon