From: Dave Chinner <david@fromorbit.com>
To: Andreas Wiese <aw-lkml@meterriblecrew.net>
Cc: xfs@oss.sgi.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
Subject: Re: fallocate() on XFS clobbers S*ID-bits
Date: Fri, 8 Oct 2010 10:24:51 +1100 [thread overview]
Message-ID: <20101007232451.GO4681@dastard> (raw)
In-Reply-To: <20101007183418.GC5621@incendiary.meterriblecrew.net>
[ 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
next parent reply other threads:[~2010-10-07 23:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101007183418.GC5621@incendiary.meterriblecrew.net>
2010-10-07 23:24 ` Dave Chinner [this message]
2010-10-08 9:26 ` fallocate() on XFS clobbers S*ID-bits Andreas Wiese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101007232451.GO4681@dastard \
--to=david@fromorbit.com \
--cc=aw-lkml@meterriblecrew.net \
--cc=ciaran.mccreesh@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox