From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 17 Mar 2021 13:01:19 -0400 From: Vivek Goyal Message-ID: <20210317170119.GE324911@redhat.com> References: <20210316160147.289193-1-vgoyal@redhat.com> <20210316160147.289193-2-vgoyal@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Virtio-fs] [PATCH 1/1] fuse: send file mode updates using SETATTR List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, virtio-fs-list , Seth Forshee On Wed, Mar 17, 2021 at 04:43:35PM +0100, Miklos Szeredi wrote: > On Tue, Mar 16, 2021 at 5:02 PM Vivek Goyal wrote: > > > > If ACL changes, it is possible that file mode permission bits change. As of > > now fuse client relies on file server to make those changes. But it does > > not send enough information to server so that it can decide where SGID > > bit should be cleared or not. Server does not know if caller has CAP_FSETID > > or not. It also does not know what are caller's group memberships and if any > > of the groups match file owner group. > > Right. So what about performing the capability and group membership > check in the client and sending the result of this check to the > server? Hi Miklos, But that will still be non-atomic, right? I mean server probably will do setxattr first, then check if SGID was cleared or not, and if it has not been cleared, then it needs to set the mode. IOW, we still have two operations (setxattr followed by mode setting). I had thought about that option. But could not understand what does it buy us as opposed to guest sending a SETATTR. > > Yes, need to extend fuse_setxattr_in. Ok. > > There's still a race with uid and gid changing on the underlying > filesystem, so the attributes need to be refreshed, but I don't think > that's a big worry. Yes, attributes will need to be refreshed. Thanks Vivek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A2D0C433E0 for ; Wed, 17 Mar 2021 17:02:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E490764E89 for ; Wed, 17 Mar 2021 17:02:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232653AbhCQRBy (ORCPT ); Wed, 17 Mar 2021 13:01:54 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:29737 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232650AbhCQRB3 (ORCPT ); Wed, 17 Mar 2021 13:01:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616000488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Wpyt/V/SL83d7rfSEN24xJ3PtTzDk8RCGWnV2AMlmvs=; b=chKp+rP96Dzgcl/zzkMSDFcgzFJIwU0x7CRfN4Wg2lF90bYZnGOsGkXCSn6Ne8U/WzU54v 2SalmVkl3s77+pE41hV1nxnL8r/Vj2nNELmTYYP6fxikt2M/4rhm2XkJsrelJBVhIE0QQb F5GAn+z/DSGmgxPAVXZlWRNZ0gVC0xs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-224-Q52ep2ThPh-TZnGpvxGPfA-1; Wed, 17 Mar 2021 13:01:25 -0400 X-MC-Unique: Q52ep2ThPh-TZnGpvxGPfA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8326B88128E; Wed, 17 Mar 2021 17:01:23 +0000 (UTC) Received: from horse.redhat.com (ovpn-116-32.rdu2.redhat.com [10.10.116.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id EF5B25D6AC; Wed, 17 Mar 2021 17:01:19 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 62B8A220BCF; Wed, 17 Mar 2021 13:01:19 -0400 (EDT) Date: Wed, 17 Mar 2021 13:01:19 -0400 From: Vivek Goyal To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, virtio-fs-list , Luis Henriques , "Dr. David Alan Gilbert" , Seth Forshee Subject: Re: [PATCH 1/1] fuse: send file mode updates using SETATTR Message-ID: <20210317170119.GE324911@redhat.com> References: <20210316160147.289193-1-vgoyal@redhat.com> <20210316160147.289193-2-vgoyal@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Mar 17, 2021 at 04:43:35PM +0100, Miklos Szeredi wrote: > On Tue, Mar 16, 2021 at 5:02 PM Vivek Goyal wrote: > > > > If ACL changes, it is possible that file mode permission bits change. As of > > now fuse client relies on file server to make those changes. But it does > > not send enough information to server so that it can decide where SGID > > bit should be cleared or not. Server does not know if caller has CAP_FSETID > > or not. It also does not know what are caller's group memberships and if any > > of the groups match file owner group. > > Right. So what about performing the capability and group membership > check in the client and sending the result of this check to the > server? Hi Miklos, But that will still be non-atomic, right? I mean server probably will do setxattr first, then check if SGID was cleared or not, and if it has not been cleared, then it needs to set the mode. IOW, we still have two operations (setxattr followed by mode setting). I had thought about that option. But could not understand what does it buy us as opposed to guest sending a SETATTR. > > Yes, need to extend fuse_setxattr_in. Ok. > > There's still a race with uid and gid changing on the underlying > filesystem, so the attributes need to be refreshed, but I don't think > that's a big worry. Yes, attributes will need to be refreshed. Thanks Vivek