public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* Re: fallocate() on XFS clobbers S*ID-bits
       [not found] <20101007183418.GC5621@incendiary.meterriblecrew.net>
@ 2010-10-07 23:24 ` Dave Chinner
  2010-10-08  9:26   ` Andreas Wiese
  0 siblings, 1 reply; 2+ messages in thread
From: Dave Chinner @ 2010-10-07 23:24 UTC (permalink / raw)
  To: Andreas Wiese; +Cc: xfs, Linux Kernel Mailing List, Ciaran McCreesh

[ added xfs list on cc ]

On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> 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.

ext2 does not support the fallocate syscall. How does ext4 behave?

> 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.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: fallocate() on XFS clobbers S*ID-bits
  2010-10-07 23:24 ` fallocate() on XFS clobbers S*ID-bits Dave Chinner
@ 2010-10-08  9:26   ` Andreas Wiese
  0 siblings, 0 replies; 2+ messages in thread
From: Andreas Wiese @ 2010-10-08  9:26 UTC (permalink / raw)
  To: Dave Chinner; +Cc: xfs, Linux Kernel Mailing List, Ciaran McCreesh

Dave Chinner wrote:
> [ added xfs list on cc ]
> 

Thanks. ;)

> On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> > 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.
> 
> 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.

> > 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…

> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-10-08  9:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20101007183418.GC5621@incendiary.meterriblecrew.net>
2010-10-07 23:24 ` fallocate() on XFS clobbers S*ID-bits Dave Chinner
2010-10-08  9:26   ` Andreas Wiese

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox