From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery Date: Wed, 21 Dec 2016 09:22:17 +1300 Message-ID: <878trae4g6.fsf@xmission.com> References: <0e229ec4-e3fc-dd46-c5b9-3afa0f14bfcd@gmail.com> <87bmw7pm31.fsf@xmission.com> <65dd9028-8aa8-123e-ddff-807c44079a50@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <65dd9028-8aa8-123e-ddff-807c44079a50-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Michael Kerrisk's message of "Tue, 20 Dec 2016 16:35:28 +0100") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Michael Kerrisk (man-pages)" Cc: "Serge E. Hallyn" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrey Vagin , James Bottomley , "W. Trevor King" , Alexander Viro , Jonathan Corbet List-Id: linux-api@vger.kernel.org "Michael Kerrisk (man-pages)" writes: > 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". My position is still not this merge window. I am more than happy to queue up the changes for the next one. Even on the best of days there is a reasonable chance Linus would not be happy to receive code development done in the merge window. I think there is also just a little bit of discussion that needs to happen with these new userspace APIs (below). And I have seen way too many times user space APIs added too quickly and having to be repaired afterwards. >> 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". Yes. I have no problem with that one. > 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. I am not quite sold on the name NS_GET_CREATOR_UID. NS_GET_OWNER_UID seems to match the code better. The owner is the creator but the important part seems to be the ownership not the act of creation. > 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? Something like that. But yes something we can wire up to ns_capable_noaudit and be told the result. That will let the LSMs and any future kerel changes have their say, without any extra maintenance burden in the kernel. What I really don't want is for userspace to start depending on the current formula being the only factors that say if it has a capabliltiy in a certain situation because in practice that just isn't true. Permission checks just keep evoloving in the kernel. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out02.mta.xmission.com ([166.70.13.232]:37686 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765845AbcLTUZd (ORCPT ); Tue, 20 Dec 2016 15:25:33 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: "Michael Kerrisk \(man-pages\)" Cc: "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 References: <0e229ec4-e3fc-dd46-c5b9-3afa0f14bfcd@gmail.com> <87bmw7pm31.fsf@xmission.com> <65dd9028-8aa8-123e-ddff-807c44079a50@gmail.com> Date: Wed, 21 Dec 2016 09:22:17 +1300 In-Reply-To: <65dd9028-8aa8-123e-ddff-807c44079a50@gmail.com> (Michael Kerrisk's message of "Tue, 20 Dec 2016 16:35:28 +0100") Message-ID: <878trae4g6.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery Sender: linux-fsdevel-owner@vger.kernel.org List-ID: "Michael Kerrisk (man-pages)" writes: > 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". My position is still not this merge window. I am more than happy to queue up the changes for the next one. Even on the best of days there is a reasonable chance Linus would not be happy to receive code development done in the merge window. I think there is also just a little bit of discussion that needs to happen with these new userspace APIs (below). And I have seen way too many times user space APIs added too quickly and having to be repaired afterwards. >> 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". Yes. I have no problem with that one. > 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. I am not quite sold on the name NS_GET_CREATOR_UID. NS_GET_OWNER_UID seems to match the code better. The owner is the creator but the important part seems to be the ownership not the act of creation. > 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? Something like that. But yes something we can wire up to ns_capable_noaudit and be told the result. That will let the LSMs and any future kerel changes have their say, without any extra maintenance burden in the kernel. What I really don't want is for userspace to start depending on the current formula being the only factors that say if it has a capabliltiy in a certain situation because in practice that just isn't true. Permission checks just keep evoloving in the kernel. Eric