From: Jeff Layton <jlayton@kernel.org>
To: Xiubo Li <xiubli@redhat.com>,
idryomov@gmail.com, Ceph Development <ceph-devel@vger.kernel.org>
Cc: vshankar@redhat.com, mchangir@redhat.com, stable@vger.kernel.org
Subject: Re: [PATCH] ceph: update the time stamps and try to drop the suid/sgid
Date: Mon, 13 Feb 2023 08:09:54 -0500 [thread overview]
Message-ID: <3225027aae8a868ae8b57441c28047710c5356e4.camel@kernel.org> (raw)
In-Reply-To: <0700f314-63fa-9324-94d2-5815daca2734@redhat.com>
On Mon, 2023-02-13 at 20:59 +0800, Xiubo Li wrote:
> On 13/02/2023 20:37, Jeff Layton wrote:
> > On Mon, 2023-02-13 at 19:10 +0800, xiubli@redhat.com wrote:
> > > From: Xiubo Li <xiubli@redhat.com>
> > >
> > > The fallocate will try to clear the suid/sgid if a unprevileged user
> > > changed the file.
> > >
> > > There is no Posix item requires that we should clear the suid/sgid
> > > in fallocate code path but this is the default behaviour for most of
> > > the filesystems and the VFS layer. And also the same for the write
> > > code path, which have already support it.
> > >
> > Huh, you're right. It really doesn't say anything about the timestamps
> > or setuid bits:
> >
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
> >
> >
> > That's arguably a bug in the spec. It really does need to do those
> > things.
>
> Yeah.
>
Actually, posix_fallocate doesn't do hole punching. It just ensures that
blocks are reserved to back future writes. Given that that's not
something "observable" and won't change the contents of the file, then
there really is no need to change the times and clear set{u,g}id bits
there.
Linux' fallocate is different. It's a GNU API not covered by POSIX, and
can result in an observable change to the contents of the file. There,
we _must_ clear the setuid/setgid bits and update timestamps, at least
in the cases where the content can change.
> Also the kernel fuse code and libfuse also need to be improved to make
> ceph-fuse work.
>
> Thanks Jeff.
>
> - Xiubo
>
> > > And also we need to update the time stamps since the fallocate will
> > > change the file contents.
> > >
> > > Cc: stable@vger.kernel.org
> > > URL: https://tracker.ceph.com/issues/58054
> > > Signed-off-by: Xiubo Li <xiubli@redhat.com>
> > > ---
> > > fs/ceph/file.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> > > index 903de296f0d3..dee3b445f415 100644
> > > --- a/fs/ceph/file.c
> > > +++ b/fs/ceph/file.c
> > > @@ -2502,6 +2502,9 @@ static long ceph_fallocate(struct file *file, int mode,
> > > loff_t endoff = 0;
> > > loff_t size;
> > >
> > > + dout("%s %p %llx.%llx mode %x, offset %llu length %llu\n", __func__,
> > > + inode, ceph_vinop(inode), mode, offset, length);
> > > +
> > > if (mode != (FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
> > > return -EOPNOTSUPP;
> > >
> > > @@ -2539,6 +2542,10 @@ static long ceph_fallocate(struct file *file, int mode,
> > > if (ret < 0)
> > > goto unlock;
> > >
> > > + ret = file_modified(file);
> > > + if (ret)
> > > + goto put_caps;
> > > +
> > > filemap_invalidate_lock(inode->i_mapping);
> > > ceph_fscache_invalidate(inode, false);
> > > ceph_zero_pagecache_range(inode, offset, length);
> > > @@ -2554,6 +2561,7 @@ static long ceph_fallocate(struct file *file, int mode,
> > > }
> > > filemap_invalidate_unlock(inode->i_mapping);
> > >
> > > +put_caps:
> > > ceph_put_cap_refs(ci, got);
> > > unlock:
> > > inode_unlock(inode);
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> >
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2023-02-13 13:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 11:10 [PATCH] ceph: update the time stamps and try to drop the suid/sgid xiubli
2023-02-13 12:37 ` Jeff Layton
2023-02-13 12:59 ` Xiubo Li
2023-02-13 13:09 ` Jeff Layton [this message]
2023-02-13 13:21 ` Xiubo Li
-- strict thread matches above, loose matches on Subject: below --
2023-02-13 11:28 xiubli
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=3225027aae8a868ae8b57441c28047710c5356e4.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=mchangir@redhat.com \
--cc=stable@vger.kernel.org \
--cc=vshankar@redhat.com \
--cc=xiubli@redhat.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