Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3480347pxv; Mon, 28 Jun 2021 05:36:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyy49VMINfN3HPZDglTzx/61MpxXRHP8zNsxszTBDHQluiAhZ1qpznKM9UqOQX5QS/keZe/ X-Received: by 2002:a17:906:1951:: with SMTP id b17mr24498767eje.468.1624883810795; Mon, 28 Jun 2021 05:36:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624883810; cv=none; d=google.com; s=arc-20160816; b=JltuQsELD/R95HXotoasITEFIzmEVfjsc778DDjpQba8Nfsncji7ak0IxhvQMmqgzs htr1dRlIxuaUbSpKw0yUL4EPUgh1T8iCnLIJkRrM392vjupB/spmYQLzq9MybZKEUoaK moMd3uvdkLTJuM0ZUl99LfEniDCm35GququbtP3/l+VzphgwenKAozwESUTL1GlQLwIO p/P7GeSw3uSbEK4t7UQAsyERFzX5iFHPeQadGjSbONsBqYy/Ji8uXsPRgW5z2SNQACw1 QUhQeHVyqf3YXd3HeVRT7aBQAewKxdKN/dQ8oxsI5QEWRT7rpzY9SRHMRM4eDTlsuUE5 lOfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=nHjSlz5Os8d82lImUo7pjvqiAFRuhfwOyS1h5u2Q+pM=; b=UuE6xXxGWuF4rT3/EhMzN7+EtxOTQHN/dfalFKLAGRyeGKj7PCHWFz3L65BV+8jPPr nOMMYxnAMe1yC87f1YbCRSpYKmVz74xXi4RzM5ZcGBBi5ipurMtNfav8wvUC4sR6GtMk DzYBysR4CyOwlxQ0Tqneeizq6tCdlKKmy25Tnj+/prGziv72KzMQbzP84RNJHWcpwZ4O GxW4H7ShgkUaHtdkbkOdrFoJdstbnjWqAyWPZFIoGIOO+lJws6zUlR9UsJ5GK4Yl1dQ0 1/XsNI1l1C9B9cSdCPSonfbZY5Ffe6QAZqiFVmCoW2W/9k/oiJuYc814ekriztRQLlYP fYjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ce26si12820691ejc.40.2021.06.28.05.36.27; Mon, 28 Jun 2021 05:36:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233004AbhF1MgF (ORCPT + 99 others); Mon, 28 Jun 2021 08:36:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:51756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232598AbhF1MgE (ORCPT ); Mon, 28 Jun 2021 08:36:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id AE94261C69; Mon, 28 Jun 2021 12:33:36 +0000 (UTC) Date: Mon, 28 Jun 2021 14:33:33 +0200 From: Christian Brauner To: Vivek Goyal Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, virtio-fs@redhat.com, dwalsh@redhat.com, dgilbert@redhat.com, berrange@redhat.com Subject: Re: [PATCH 1/1] xattr: Allow user.* xattr on symlink/special files with CAP_SYS_RESOURCE Message-ID: <20210628123333.4lueag2a5uhdsfor@wittgenstein> References: <20210625191229.1752531-1-vgoyal@redhat.com> <20210625191229.1752531-2-vgoyal@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210625191229.1752531-2-vgoyal@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 25, 2021 at 03:12:29PM -0400, Vivek Goyal wrote: > As of now user.* xattrs are allowed only on regular files and directories. > And in case of directories if sticky bit is set, then it is allowed > only if caller is owner or has CAP_FOWNER. > > "man xattr" suggests that primary reason behind this restrcition is that > users can set unlimited amount of "user.*" xattrs on symlinks and special > files and bypass quota checks. Following is from man page. > > "These differences would allow users to consume filesystem resources in > a way not controllable by disk quotas for group or world writable spe‐ > cial files and directories" > > Capability CAP_SYS_RESOURCE allows for overriding disk quota limits. If > being able to bypass quota is primary reason behind these restrictions, > can we relax these restrictions if caller has CAP_SYS_RESOURCE. > > Signed-off-by: Vivek Goyal > --- I think this change is fine especially since it seems to solve a real problem there since it prevents relabeling for virtiofsd.