Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2425967pxb; Sat, 30 Jan 2021 02:11:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJxZ/hBcxhJuunxlWVm31Wt3Mh4/Fg9h5sbwos0+l0ljNNPYC1M9KZGdC3wlLLHLlNAdpep3 X-Received: by 2002:a17:906:eca7:: with SMTP id qh7mr8446621ejb.437.1612001466695; Sat, 30 Jan 2021 02:11:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612001466; cv=none; d=google.com; s=arc-20160816; b=kyfS3IQ3mFAuNj9augmIj1LqoheTpQs4DIfTsUhdjpQn5xBvkepDpF1w1of4EYwdww NWIfVZtOPdyvQhbCxlqcCm/mpzZb7tZVy74O6MfI5b9vR3gyjrz2n5mK+Gzw48X2N8cA pOFOTAY23UhdfXTh4+Ljzfu6ND7ISQVB7d9HqPfvJQFcuq0j2DzjXVutBlnlYRO2GX0t FVu4XotA7EKTogGKo+a4sTh/deSdyka+6w0qBUk2AE1efuG6PVhqJ4K+63IlAP7pblmJ 3YmxpGG1fceHPWEX1yhxn5I4Bzhi8eNneLARl5n6AgCn0RDZzYzDjGRgBEfxjNDKHz7b SvDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=mHC7IkcnVB0NlswDfU0aVHA8VVv6vgcrPW0g6kevMHI=; b=VV/JKDJGVqa51a9WRJOrol2bkO7fM2i3dM+PvE0Ax5BnDtbO0z0M6v2o/DEhIkMSmA 0ZgnwNLt9rC3eJDnXGtV+NaV1WasrfAIQHfmW6S0H0LxInRkkrpgdI6V+aeB/yyGH786 D64ov+6XWKiuD6BQVk/J/boVXBXODn7yXRX0pfzaER+CQTSIWIQVZB45UtZjiK/e0LN+ 6NS2Pm6911aogXsaYDiK6UEmU9icoW1i8RD4B1ooIAw1UWr+Ct0j4Si3wpP3zz0ZzL8w vFwvDbhyx1ThwIkz8QZrES3jfnyOTnBfKmEVbyVK+kz1Ea3FV5lIalEQ7DASpIRLymkq amJA== 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 dg6si6671839edb.485.2021.01.30.02.10.43; Sat, 30 Jan 2021 02:11:06 -0800 (PST) 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 S232053AbhA3KJm (ORCPT + 99 others); Sat, 30 Jan 2021 05:09:42 -0500 Received: from mail.hallyn.com ([178.63.66.53]:45820 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231765AbhA3CJD (ORCPT ); Fri, 29 Jan 2021 21:09:03 -0500 Received: by mail.hallyn.com (Postfix, from userid 1001) id D174C9AC; Fri, 29 Jan 2021 20:06:52 -0600 (CST) Date: Fri, 29 Jan 2021 20:06:52 -0600 From: "Serge E. Hallyn" To: "Eric W. Biederman" Cc: "Serge E. Hallyn" , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Christian Brauner Subject: Re: [PATCH 2/2] security.capability: fix conversions on getxattr Message-ID: <20210130020652.GB7163@mail.hallyn.com> References: <20210119162204.2081137-1-mszeredi@redhat.com> <20210119162204.2081137-3-mszeredi@redhat.com> <8735yw8k7a.fsf@x220.int.ebiederm.org> <20210128165852.GA20974@mail.hallyn.com> <87o8h8x1a6.fsf@x220.int.ebiederm.org> <20210129154839.GC1130@mail.hallyn.com> <87im7fuzdq.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87im7fuzdq.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 29, 2021 at 04:55:29PM -0600, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > > > On Thu, Jan 28, 2021 at 02:19:13PM -0600, Eric W. Biederman wrote: > >> "Serge E. Hallyn" writes: > >> > >> > On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W. Biederman wrote: > >> >> Miklos Szeredi writes: > >> >> > >> >> > If a capability is stored on disk in v2 format cap_inode_getsecurity() will > >> >> > currently return in v2 format unconditionally. > >> >> > > >> >> > This is wrong: v2 cap should be equivalent to a v3 cap with zero rootid, > >> >> > and so the same conversions performed on it. > >> >> > > >> >> > If the rootid cannot be mapped v3 is returned unconverted. Fix this so > >> >> > that both v2 and v3 return -EOVERFLOW if the rootid (or the owner of the fs > >> >> > user namespace in case of v2) cannot be mapped in the current user > >> >> > namespace. > >> >> > >> >> This looks like a good cleanup. > >> > > >> > Sorry, I'm not following. Why is this a good cleanup? Why should > >> > the xattr be shown as faked v3 in this case? > >> > >> If the reader is in &init_user_ns. If the filesystem was mounted in a > >> user namespace. Then the reader looses the information that the > > > > Can you be more precise about "filesystem was mounted in a user namespace"? > > Is this a FUSE thing, the fs is marked as being mounted in a non-init userns? > > If that's a possible case, then yes that must be represented as v3. Using > > is_v2header() may be the simpler way to check for that, but the more accurate > > check would be "is it v2 header and mounted by init_user_ns". > > I think the filesystems current relevant are fuse,overlayfs,ramfs,tmpfs. > > > Basically yes, in as many cases as possible we want to just give a v2 > > cap because more userspace knows what to do with that, but a non-init-userns > > mounted fs which provides a v2 fscap should have it represented as v3 cap > > with rootid being the kuid that owns the userns. > > That is the case we that is being fixed in the patch. > > > Or am I still thinking wrongly? Wouldn't be entirely surprised :) > > No you got it. So then can we make faking a v3 gated on whether sb->s_user_ns != &init_user_ns ?