From: Xiubo Li <xiubli@redhat.com>
To: Jeff Layton <jlayton@kernel.org>,
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 21:21:20 +0800 [thread overview]
Message-ID: <9741848e-4fa6-9c70-8189-4b8614389501@redhat.com> (raw)
In-Reply-To: <3225027aae8a868ae8b57441c28047710c5356e4.camel@kernel.org>
On 13/02/2023 21:09, Jeff Layton wrote:
> 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.
>
Okay, get it.
Thank you Jeff for detailed explaining about this.
- Xiubo
>> 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>
>>>
--
Best Regards,
Xiubo Li (李秀波)
Email: xiubli@redhat.com/xiubli@ibm.com
Slack: @Xiubo Li
next prev parent reply other threads:[~2023-02-13 13:23 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
2023-02-13 13:21 ` Xiubo Li [this message]
-- 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=9741848e-4fa6-9c70-8189-4b8614389501@redhat.com \
--to=xiubli@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=mchangir@redhat.com \
--cc=stable@vger.kernel.org \
--cc=vshankar@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