Linux kernel -stable discussions
 help / color / mirror / Atom feed
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


  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