fallocate() on XFS clobbers S*ID-bits
Hello.
I (with support from Cc'ed Ciaran) just noticed some odd behaviour with fallocate() on XFS. After open()ing some file and setting it S*ID via fchmod(), S*ID bits vanish after calling fallocate() — as supposed to for non-root users, but it also happens for root.
Is this intended behaviour or did we spot a bug here?
At least on ext2 it works as expected, thus I guess it's the latter one.
I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master doesn't seem to address this issue.
HAND & LG -- aw
Signature · 1 line
This signature is intentionally left blank.
[ added xfs list on cc ]
Quoted 10 lines · Andreas Wiese
Hello.
I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
fallocate()on XFS. After open()ing some file and setting it S*ID viafchmod(), S*ID bits vanish after callingfallocate()— as supposed to for non-root users, but it also happens for root.Is this intended behaviour or did we spot a bug here?
At least on ext2 it works as expected, thus I guess it's the latter one.
ext2 does not support the fallocate syscall. How does ext4 behave?
Quoted 2 lines
I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master doesn't seem to address this issue.
XFS has always cleared SUID/SGID bits when doing preallocation (via XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for fallocate, I'd argue that the XFS behaviour is the on that should be followed.
It'd be a bit silly for two different preallocation interfaces to have different behaviour w.r.t. SUID bits, but it's not clear to me which behaviour is correct. I'm happy to defer to whoever can say what the behaviour is supposed to be here...
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Dave Chinner
[ added xfs list on cc ]
Thanks. ;)
Quoted 8 lines · Andreas Wiese
Quoted 7 lines
Hello.
I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
fallocate()on XFS. After open()ing some file and setting it S*ID viafchmod(), S*ID bits vanish after callingfallocate()— as supposed to for non-root users, but it also happens for root.
Quoted 6 lines
Quoted 3 lines
Is this intended behaviour or did we spot a bug here?
At least on ext2 it works as expected, thus I guess it's the latter one.
ext2 does not support the fallocate syscall. How does ext4 behave?
Oh, crap. I first tested on tmpfs (which doesn't support fallocate, too) and had a » && errno != ENOTSUP« to avoid bailing out but forgot to warn. :/
But I did now and ext4 does _not_ touch the permissions any further.
Quoted 8 lines
Quoted 2 lines
I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master doesn't seem to address this issue.
XFS has always cleared SUID/SGID bits when doing preallocation (via
XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for fallocate, I'd argue that the XFS behaviour is the on that should be followed.
If that's consense, we at least found a bug in ext4…
Quoted 5 lines
It'd be a bit silly for two different preallocation interfaces to have different behaviour w.r.t. SUID bits, but it's not clear to me which behaviour is correct. I'm happy to defer to whoever can say what the behaviour is supposed to be here...
I would appreciate that, too.
And while on it… just tested BTRFS, which behaves like ext4 (not altering permissions). CIFS and OCFS are not testable here due to lack of according servers.
[snip…]
HAND & LG -- aw
np: Johnossi (Johnossi) — 08. Happiness a La Mode
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs