[Bug 215687] chown behavior on XFS is changed

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=215687

--- Comment #4 from Zorro Lang (zlang@redhat.com) ---
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from
comment #3)
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
> 
> On 15.03.22 09:12, bugzilla-daemon@kernel.org wrote:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=215687
> > 
> >            Summary: chown behavior on XFS is changed
> 
> Darrick, what's up with this bug reported more than ten days ago? It's a
> a regression reported the reporter even bisected to a change of yours
> (e014f37db1a2 ("xfs: use setattr_copy to set vfs inode attributes") --
> see the ticket for details) – but nothing happened afaics. Did the
> discussion about this continue somewhere else or did it fall through the
> cracks?
> 
> Anyway: I'm adding it to regzbot, my Linux kernel regression tracking bot:
> 
> #regzbot ^introduced e014f37db1a2d109afa750042ac4d69cf3e3d88e
> #regzbot title xfs: chown behavior changed
> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215687
> #regzbot ignore-activity
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> 
> P.S.: As the Linux kernel's regression tracker I'm getting a lot of
> reports on my table. I can only look briefly into most of them and lack
> knowledge about most of the areas they concern. I thus unfortunately
> will sometimes get things wrong or miss something important. I hope
> that's not the case here; if you think it is, don't hesitate to tell me
> in a public reply, it's in everyone's interest to set the public record
> straight.

Darrick has talked about it with us in IRC (as below, hope that helps):

2022-03-16 00:02 < djwong> all that setgid dropping came out of complaints that
xfs didn't handle that the same way as all the other linux filesystems
2022-03-16 00:03 < djwong> zlang: ^^^
2022-03-16 00:04 < djwong> originally the xfs setattr more or less did what the
vfs setattr did
2022-03-16 00:04 < djwong> but now people update the vfs setattr and they don't
update the xfs version
2022-03-16 00:05 < djwong> so is this a "unique feature of xfs"?
2022-03-16 00:06 < djwong> inconsistent behavior from xfs?
2022-03-16 00:06 < djwong> or just bitrotting crap in the kernel?
2022-03-16 01:46 < zlang> djwong, sandeen: Thanks! I don't know if there's a
standard describe that, just thought about how should we backport it, hope no
customer depend on the old behavior :)
2022-03-16 01:55 < zlang> That would be great if no customer depend on that, or
they might complain, if their script expect a program lose S_ISUID and S_ISGID
after chown, but not, then cause permission/security problem
2022-03-16 02:00 < zlang> So if we backport that, we might be better to warn
that in doc. To remind them if they hope to "lose" S_ISUID and S_ISGID bits,
better to do that clearly and definitely
2022-03-16 02:01 < djwong> <nod> all that setgid handling is ... very murky
2022-03-16 02:01 < djwong> it at least matches ext4 and btrfs now :P


And another bug report (which can be closed DUP on this one):
https://bugzilla.kernel.org/show_bug.cgi?id=215693

Darrick has reviewed and replied in IRC (update as below):

2022-03-16 17:10 < zlang> djwong: Did you notice that generic/673 fails on
xfs-5.18-merge-1, looks similar with that chown problem
2022-03-16 17:30 < zlang> https://bugzilla.kernel.org/show_bug.cgi?id=215693
2022-03-16 17:32 < zlang> But this's about reflink (not chown), and sometimes
it lose sgid bit after reflink, sometimes not ...
2022-03-16 17:39 < zlang> So I report a seperate bug to track this question,
please help to review and make sure the new expected behaviors. Sorry to bring
this trouble to you
2022-03-17 00:36 < djwong> zlang: both setgid changes that you filed bugs
against stem from the same setattr_copy issue
2022-03-17 00:37 < djwong> also generic/673 is wrong, see
https://lore.kernel.org/fstests/164740142591.3371628.12793589713189041823.stgit@magnolia/T/#u

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.