From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758516AbcLTPfk (ORCPT ); Tue, 20 Dec 2016 10:35:40 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:35821 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752237AbcLTPfg (ORCPT ); Tue, 20 Dec 2016 10:35:36 -0500 From: "Michael Kerrisk (man-pages)" 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> 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 Message-ID: <65dd9028-8aa8-123e-ddff-807c44079a50@gmail.com> Date: Tue, 20 Dec 2016 16:35:28 +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: <87bmw7pm31.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 Hello Eric, On 12/19/2016 11:53 PM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Eric, >> >> The code proposed in this patch series is pretty small. Is there any >> chance we could make the 4.10 merge window, if the changes seem >> acceptable to you? > > I see why you are asking but I am not comfortable with aiming for > the merge window that is on-going and could close at any moment. > I have seen recenly too many patches that should work fine have > some odd minor issue. Like an extra _ in a label used in an ifdef > that resulted in memory stomps. Linus might be more brave but i would > rather wait until the next merge window, so I don't need to worry about > spoiling anyone's holidays with a typo someone over looked. I'll just gently ask if you'll reconsider and take another look at the patches. They patches are very small, and don't change any existing behavior. And if we see a problem in the next weeks they could be pulled. In the meantime, I'd be aiming to publicize this API somewhat, so that we might get some eyeballs to spot design bugs. But, I do understand your position, if the answer is still "not for this merge window". > At first glance these patches seem reasonable. I don't see any problem > with the ioctls you have added. > > That said I have a question. Should we provide a more direct way to > find the answer to your question? Something like the access system > call? > > I think a more direct answer would be more maintainable in the long run > as it does not bind tools to specific implementation details in the > future. Which could allow us to account for LSM policies and the like. My thoughts: 1. Regarding NS_GET_NSTYPE... It always struck me as a little odd that you could ask setns() to check if the supplied FD referred to a certain type of NS (and thus, in a round about way, setns() gives us the same information as NS_GET_NSTYPE), but you can't directly ask what the NS type is. The fact that setns() has this facility suggests that there could be other uses for the operation "tell me what type of NS this FD refers to". 2. Regarding NS_GET_CREATOR_UID... There are defined rules about what this UID means with respect to capabilities in a namespace. It's not an implementation detail, as I understand it. Also in terms of introspecting to try to understand the structure of namespaces on a running system, knowing this UID is useful in and of itself. 3. NS_GET_NSTYPE and NS_GET_CREATOR_UID solve my problem, but obviously your idea would make life simpler for user space. Am I correct to understand that you mean an API that takes three pieces of info: a PID, a capability, and an fd referring to a /proc/PID/ns/xxx, and tells us whether PID has the specified capability for operations in the specified namespace? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/