Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3401785pxk; Mon, 7 Sep 2020 11:50:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzs1a6X/J28S1wOZQney8r00XC6B7MV2GHPcj65qHxHBV20n0AP4QZhyX3Gk3y+1Dy+d76U X-Received: by 2002:aa7:db85:: with SMTP id u5mr22186064edt.316.1599504602590; Mon, 07 Sep 2020 11:50:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599504602; cv=none; d=google.com; s=arc-20160816; b=fMLZoWPQkBR+epOUySeYw31AHDyECmOvhbUWNFQf9bB/ZMO2WSPG9UOdX9a+leRyEe Lv38qzZUUbrXH7qcsPoYxpXjlGMRk19jDlX4oKVY76R23PPDgni/twinXo+sLVRGMr0j s1cOrj/7XqILQnNFfbObyLm/HuD/owLPdFBNm5TpQ/UEQimz1r0dhzY3zWMM0WEu4MnK aUOSfEeAaFZTns5B1+9z7yJlp/3yFLPCoomYUTrisidcveTCbAWeM4jHLZ3e6D5IzOBY Ar7eIL1ITcAhpB9Yo0GFuuLIW9gDck/uUnKOwXk1tR/mZD29AngFMVmwDcPQmSJB1oGf 4Phw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Ejoiz+0X8N2EDvNXLEEDKFZhHF5Y6bzLOc0Mv59Z0Ks=; b=QbDK0WQJIpgorIZ1kmPkh8UZACG1GcgGCfTWF3/sGI9PQoN/CEczyHXXA+xT3P+wA5 1ZgXpjO99lY5kfP14iADcj67NLN9Y9Ka2Cez/TByDlAR3A+10i+WGFTVgBMAvBUPqVou oUu5JT2ilqilSHX59Asf2YLbz35EA+ydOIPJuf/ZlW2jLBnmD6jrGszG5PygcoOhnwg7 7RRfxPWamqkKCR5PbrN8gwI8Vq5z4r9dVzyF0SlSOsyT11HK7fDecpAeB20ITn5v80Hv 1NNccjEjsOXSUaB3Uzbr3qSm28dKbMNk0Zf0EL/wwnwO752RovD0Q4GboaajamjnEqCt Ogow== 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 s22si9619411ejj.630.2020.09.07.11.49.39; Mon, 07 Sep 2020 11:50:02 -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 S1729662AbgIGSRz (ORCPT + 99 others); Mon, 7 Sep 2020 14:17:55 -0400 Received: from vmicros1.altlinux.org ([194.107.17.57]:48282 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726458AbgIGSRy (ORCPT ); Mon, 7 Sep 2020 14:17:54 -0400 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 3A8DF72CCE9; Mon, 7 Sep 2020 21:17:50 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 2F0237CFD1F; Mon, 7 Sep 2020 21:17:50 +0300 (MSK) Date: Mon, 7 Sep 2020 21:17:50 +0300 From: "Dmitry V. Levin" To: "Eric W. Biederman" , Michael Kerrisk , Arnd Bergmann Cc: Alexander Viro , Serge Hallyn , Andrei Vagin , =?utf-8?B?w4Frb3M=?= Uzonyi , Linux FS-devel Mailing List , linux-man@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs/nsfs.c: fix ioctl support of compat processes Message-ID: <20200907181749.GA16472@altlinux.org> References: <20200724001248.GC25522@altlinux.org> <20200724102848.GA1654@altlinux.org> <878sf8ogl4.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <878sf8ogl4.fsf@x220.int.ebiederm.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Jul 24, 2020 at 02:31:19PM -0500, Eric W. Biederman wrote: > Michael, > > As the original author of NS_GET_OWNER_UID can you take a look at this? This is a gentle reminder that my patch hasn't been applied, the problem reported by Ákos Uzonyi hasn't been fixed, and the example in ioctl_ns(2) manual page doesn't work when e.g. it's compiled with -m32 on a 64-bit kernel. > "Dmitry V. Levin" writes: > > On Fri, Jul 24, 2020 at 11:20:26AM +0200, Arnd Bergmann wrote: > >> On Fri, Jul 24, 2020 at 2:12 AM Dmitry V. Levin wrote: > >> > > >> > According to Documentation/driver-api/ioctl.rst, in order to support > >> > 32-bit user space running on a 64-bit kernel, each subsystem or driver > >> > that implements an ioctl callback handler must also implement the > >> > corresponding compat_ioctl handler. The compat_ptr_ioctl() helper can > >> > be used in place of a custom compat_ioctl file operation for drivers > >> > that only take arguments that are pointers to compatible data > >> > structures. > >> > > >> > In case of NS_* ioctls only NS_GET_OWNER_UID accepts an argument, and > >> > this argument is a pointer to uid_t type, which is universally defined > >> > to __kernel_uid32_t. > >> > >> This is potentially dangerous to rely on, as there are two parts that > >> are mismatched: > >> > >> - user space does not see the kernel's uid_t definition, but has its own, > >> which may be either the 16-bit or the 32-bit type. 32-bit uid_t was > >> introduced with linux-2.3.39 in back in 2000. glibc was already > >> using 32-bit uid_t at the time in user space, but uclibc only changed > >> in 2003, and others may have been even later. > >> > >> - the ioctl command number is defined (incorrectly) as if there was no > >> argument, so if there is any user space that happens to be built with > >> a 16-bit uid_t, this does not get caught. > > > > Note that NS_GET_OWNER_UID is provided on 32-bit architectures, too, so > > this 16-bit vs 32-bit uid_t issue was exposed to userspace long time ago > > when NS_GET_OWNER_UID was introduced, and making NS_GET_OWNER_UID > > available for compat processes won't make any difference, as the mismatch > > is not between native and compat types, but rather between 16-bit and > > 32-bit uid_t types. > > > > I agree it would be correct to define NS_GET_OWNER_UID as > > _IOR(NSIO, 0x4, uid_t) instead of _IO(NSIO, 0x4), but nobody Cc'ed me > > on this topic when NS_GET_OWNER_UID was discussed, and that ship has long > > sailed. > > > >> > This change fixes compat strace --pidns-translation. > >> > > >> > Note: when backporting this patch to stable kernels, commit > >> > "compat_ioctl: add compat_ptr_ioctl()" is needed as well. > >> > > >> > Reported-by: Ákos Uzonyi > >> > Fixes: 6786741dbf99 ("nsfs: add ioctl to get an owning user namespace for ns file descriptor") > >> > Cc: stable@vger.kernel.org # v4.9+ > >> > Signed-off-by: Dmitry V. Levin > >> > --- > >> > fs/nsfs.c | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> > diff --git a/fs/nsfs.c b/fs/nsfs.c > >> > index 800c1d0eb0d0..a00236bffa2c 100644 > >> > --- a/fs/nsfs.c > >> > +++ b/fs/nsfs.c > >> > @@ -21,6 +21,7 @@ static long ns_ioctl(struct file *filp, unsigned int ioctl, > >> > static const struct file_operations ns_file_operations = { > >> > .llseek = no_llseek, > >> > .unlocked_ioctl = ns_ioctl, > >> > + .compat_ioctl = compat_ptr_ioctl, > >> > }; > >> > > >> > static char *ns_dname(struct dentry *dentry, char *buffer, int buflen) > > Thank you, > Eric -- ldv