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... > > 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). >

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.

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... >>> >>> 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(a)lists.podman.io To unsubscribe send an email to podman-leave(a)lists.podman.io

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... >>>>> >>>>> 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(a)lists.podman.io >> To unsubscribe send an email to podman-leave(a)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 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.

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... >>>>>>> >>>>>>> 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(a)lists.podman.io >>>> To unsubscribe send an email to podman-leave(a)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(a)lists.podman.io > To unsubscribe send an email to podman-leave(a)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 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... >>>>>>>>> >>>>>>>>> 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(a)lists.podman.io >>>>>> To unsubscribe send an email to podman-leave(a)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(a)lists.podman.io >>> To unsubscribe send an email to podman-leave(a)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 _______________________________________________ Podman mailing list -- podman(a)lists.podman.io To unsubscribe send an email to podman-leave(a)lists.podman.io