Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938712AbcLVHUk (ORCPT ); Thu, 22 Dec 2016 02:20:40 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36809 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758598AbcLVHUg (ORCPT ); Thu, 22 Dec 2016 02:20:36 -0500 Subject: Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery To: "Eric W. Biederman" References: <0e229ec4-e3fc-dd46-c5b9-3afa0f14bfcd@gmail.com> <87bmw7pm31.fsf@xmission.com> <65dd9028-8aa8-123e-ddff-807c44079a50@gmail.com> <878trae4g6.fsf@xmission.com> <8737hi5e67.fsf@xmission.com> <24b5d73e-0071-6be4-fa5b-391eb8aa0f78@gmail.com> <87a8boq03m.fsf@xmission.com> Cc: mtk.manpages@gmail.com, "Serge E. Hallyn" , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrey Vagin , James Bottomley , "W. Trevor King" , Alexander Viro , Jonathan Corbet , Andrei Vagin From: "Michael Kerrisk (man-pages)" Message-ID: <142285b7-225b-fd15-3c8e-9ae2d02e82b5@gmail.com> Date: Thu, 22 Dec 2016 08:20:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87a8boq03m.fsf@xmission.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2743 Lines: 77 Hi Eric, On 12/22/2016 01:27 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hi Eric, >> >> On 12/21/2016 01:17 AM, Eric W. Biederman wrote: >>> "Michael Kerrisk (man-pages)" writes: >>> >>>> Hi Eric, >>>> >>>> On 12/20/2016 09:22 PM, Eric W. Biederman wrote: >>>>> "Michael Kerrisk (man-pages)" writes: >>>>> >>>>>> Hello Eric, >>>>>> >>>>>> On 12/19/2016 11:53 PM, Eric W. Biederman wrote: >>>>>>> "Michael Kerrisk (man-pages)" writes: >>>>>>> > >>> Now the question becomes who are the users of this? Because it just >>> occurred to me that we now have an interesting complication. Userspace >>> extending the meaning of the capability bits, and using to protect >>> additional things. Ugh. That could be a maintenance problem of another >>> flavor. Definitely not my favorite. >> >> I don't follow you here. Could you say some more about what you mean? > > I have seen user space userspace do thing such as extend CAP_SYS_REBOOT > to things such as permission to invoke "shutdown -r now". Which > depending on what a clean reboot entails could be greately increasing > the scope of CAP_SYS_REBOOT. > > I am concerned for that and similar situations that userspace > applications could lead us into situation that one wrong decision could > wind up being an unfixable mistake because fixing the mistake would > break userspsace. Okay. >>> So why are we asking the questions about what permissions a process has? >> >> My main interest here is monitoring/discovery/debugging on a running >> system. NS_GET_PARENT, NS_GET_USERNS, NS_GET_CREATOR_UID, and >> NS_GET_NSTYPE provide most of what I'd like to see. Being able to ask >> "does this process have permissions in that namespace?" would be nice >> to have in terms of understanding/debugging a system. > > If we are just looking at explanations then I seem to have been > over-engineering things. So let's just aim at the two ioctls. > Or at least the information in those ioctls. Okay. > With at least a comment on the ioctl returning the OWNER_UID that > describes why it is not a problem to if the owners uid is something like > ((uid_t)-3). Which overlaps with the space for error return codes. > > I don't know if we are fine or not, but that review comment definitely > deserves some consideration. See my reply just sent to Andrei. We should instead then just return the UID via a buffer pointed to by the ioctl() argument: ioctl(fd, NS_GET_OWNER_UID, &uid); Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/