On Thu, Jun 16, 2022 at 9:29 PM Leah Rumancik <leah.rumancik@xxxxxxxxx> wrote: > > From: "Darrick J. Wong" <djwong@xxxxxxxxxx> > > [ Upstream commit e014f37db1a2d109afa750042ac4d69cf3e3d88e ] > > Filipe Manana pointed out that XFS' behavior w.r.t. setuid/setgid > revocation isn't consistent with btrfs[1] or ext4. Those two > filesystems use the VFS function setattr_copy to convey certain > attributes from struct iattr into the VFS inode structure. > > Andrey Zhadchenko reported[2] that XFS uses the wrong user namespace to > decide if it should clear setgid and setuid on a file attribute update. > This is a second symptom of the problem that Filipe noticed. > > XFS, on the other hand, open-codes setattr_copy in xfs_setattr_mode, > xfs_setattr_nonsize, and xfs_setattr_time. Regrettably, setattr_copy is > /not/ a simple copy function; it contains additional logic to clear the > setgid bit when setting the mode, and XFS' version no longer matches. > > The VFS implements its own setuid/setgid stripping logic, which > establishes consistent behavior. It's a tad unfortunate that it's > scattered across notify_change, should_remove_suid, and setattr_copy but > XFS should really follow the Linux VFS. Adapt XFS to use the VFS > functions and get rid of the old functions. > > [1] https://lore.kernel.org/fstests/CAL3q7H47iNQ=Wmk83WcGB-KBJVOEtR9+qGczzCeXJ9Y2KCV25Q@xxxxxxxxxxxxxx/ > [2] https://lore.kernel.org/linux-xfs/20220221182218.748084-1-andrey.zhadchenko@xxxxxxxxxxxxx/ > > Fixes: 7fa294c8991c ("userns: Allow chown and setgid preservation") > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> > Reviewed-by: Christoph Hellwig <hch@xxxxxx> > Reviewed-by: Christian Brauner <brauner@xxxxxxxxxx> > Signed-off-by: Leah Rumancik <leah.rumancik@xxxxxxxxx> > --- Hi Leah, Dave has raised a concern [1] about backporting fixes in this area because there are other vfs fixes still in work. For the fix "xfs: fix up non-directory creation in SGID directories", both Christian and Christoph said it should be backported regardless [2]. I am not sure what they would have to say about this one though? Christian, Christoph, In your opinion, is this one also worth backporting regardless of possible future vfs fixes? I did test the 5.10 backports both with and without these two patches, so I could go either way. Thanks, Amir. [1] https://lore.kernel.org/linux-xfs/20220602005238.GK227878@xxxxxxxxxxxxxxxxxxx/ [2] https://lore.kernel.org/linux-xfs/CAOQ4uxg4=m9zEFbDAKXx7CP7HYiMwtsYSJvq076oKpy-OhK1uw@xxxxxxxxxxxxxx/
