Transmute flag is not inheritted on overlay fs

[Mengchi Cheng]

On Wed, 2023-04-19 02:09:37 +0000, Casey Schaufler wrote:
>
> On 4/18/2023 5:23 PM, Mengchi Cheng wrote:
> > Hello,
> >
> > On the overlay ext4 file system, we found that transmute flag is not
> > inherited by newly created sub-directories. The issue can be recreated on
> > the newest kernel(6.3.0-rc6) on qemux86-64 with following steps.
> >
> > /data directory is mounted on /dev/vdb which is a ext4 fs. It is remounted
> > as an overlay again to upperdir /home/root/data.
> > # mount -t overlay overlay -o lowerdir=/data,upperdir=/home/root/data,workdir=/home/root/data_work /data
> > Add a new smack rule and set label and flag to /data directory.
> > # echo "_ system rwxatl" > /sys/fs/smackfs/load2
> > # chsmack -a "system" /data
> > # chsmack -t /data
> > Create directories under /data.
> > # mkdir -p /data/dir1/dir2
> > And then check the smack label of dir1 and dir2.
> > # chsmack /data/dir1
> > /data/dir1 access="system"
> > # chsmack /data/dir1/dir2
> > /data/dir1/dir2 access="_"
> > We can see dir1 did not inherit transmute flag from data and dir2 got the
> > process label.
> >
> > The transmute xattr of the inode is set inside the smack_d_instantiate
> > which depends on SMK_INODE_CHANGED bit of isp->smk_flags. But the bit is
> > not set in the overlay fs mkdir function call chain. So one simple solution
> > we have is passing inode ptr into smack_dentry_create_files_as and set the
> > SMK_INODE_CHANGED bit if parent dir is transmuting. Although it looks
> > reasonable to me and we did not meet any issue in testing, I am not sure if
> > there is a better solution to it. It will be great, if experts could take
> > a look.
> 
> I will be happy to look at your solution. Please post a patch.
>

Sorry, it takes me a while to review and send out the patch.
It contains a few files because it breaks kernel API. But the core is only
in the change of smack_dentry_create_files_as.

If Roberto's patch will work, we can drop it. I posted my concern in that
thread.
https://lore.kernel.org/all/20230419192516.757220-1-mengcc@amazon.com/
 
> >
> >
> > Thanks,
> > Mengchi Cheng
> >
>