All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	Linux API <linux-api@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Andrey Vagin <avagin@openvz.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	"W. Trevor King" <wking@tremily.us>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v4 0/2] Add further ioctl() operations for namespace discovery
Date: Thu, 26 Jan 2017 17:23:46 +1300	[thread overview]
Message-ID: <87a8aea1pp.fsf@xmission.com> (raw)
In-Reply-To: <CAKgNAkjZTUSbdX0m69+TBOTM3jz_O8byH4W0SrY3wUD5gyUk1A@mail.gmail.com> (Michael Kerrisk's message of "Wed, 25 Jan 2017 16:50:22 +1300")

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:


> On 25 January 2017 at 15:28, Eric W. Biederman <ebiederm@xmission.com> wrote:

>> My concern is that the difference between returning -EOVERFLOW and
>> overflow_uid is primarily about usability.  If you haven't played with
>> the usability I don't trust that we have made the proper trade off.
>
> So, I had not initially included the no-UID-mapping case, and when you
> proposed -EOVERFLOW for that case, it seemed better.
>
> On reflection, mapping to the overflow_uid seems simpler. Taking the
> example shown in my other mail a short time ago, the unmapped UID 0
> from the outer namespace would map to the overflow_uid (which UID my
> program would print), but my program would still correctly report that
> the UID 0 process in the outer namespace might (subject to LSM checks)
> have capabilities in the inner namespace.
>
> So, it seems that reverting the EOVERFLOW change is in order (and my
> example program thus needs no changes). Does that sound reasonable to
> you?

It does.  I just care that you have thought through the tradeoffs of
that corner of the interface design.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	Linux API <linux-api@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Andrey Vagin <avagin@openvz.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	"W. Trevor King" <wking@tremily.us>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v4 0/2] Add further ioctl() operations for namespace discovery
Date: Thu, 26 Jan 2017 17:23:46 +1300	[thread overview]
Message-ID: <87a8aea1pp.fsf@xmission.com> (raw)
In-Reply-To: <CAKgNAkjZTUSbdX0m69+TBOTM3jz_O8byH4W0SrY3wUD5gyUk1A@mail.gmail.com> (Michael Kerrisk's message of "Wed, 25 Jan 2017 16:50:22 +1300")

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:


> On 25 January 2017 at 15:28, Eric W. Biederman <ebiederm@xmission.com> wrote:

>> My concern is that the difference between returning -EOVERFLOW and
>> overflow_uid is primarily about usability.  If you haven't played with
>> the usability I don't trust that we have made the proper trade off.
>
> So, I had not initially included the no-UID-mapping case, and when you
> proposed -EOVERFLOW for that case, it seemed better.
>
> On reflection, mapping to the overflow_uid seems simpler. Taking the
> example shown in my other mail a short time ago, the unmapped UID 0
> from the outer namespace would map to the overflow_uid (which UID my
> program would print), but my program would still correctly report that
> the UID 0 process in the outer namespace might (subject to LSM checks)
> have capabilities in the inner namespace.
>
> So, it seems that reverting the EOVERFLOW change is in order (and my
> example program thus needs no changes). Does that sound reasonable to
> you?

It does.  I just care that you have thought through the tradeoffs of
that corner of the interface design.

Eric

  reply	other threads:[~2017-01-26  4:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-23  9:54 [PATCH v2 0/2] Add further ioctl() operations for namespace discovery Michael Kerrisk (man-pages)
2017-01-24 21:34 ` Michael Kerrisk (man-pages)
2017-01-24 22:41   ` Eric W. Biederman
2017-01-24 22:41     ` Eric W. Biederman
     [not found]     ` <87a8aggjx5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-01-25  0:39       ` Michael Kerrisk (man-pages)
2017-01-25  0:39         ` Michael Kerrisk (man-pages)
2017-01-25  1:03 ` [PATCH v4 " Michael Kerrisk (man-pages)
2017-01-25  1:58   ` Eric W. Biederman
2017-01-25  1:58     ` Eric W. Biederman
2017-01-25  2:24     ` Michael Kerrisk (man-pages)
2017-01-25  2:26       ` Eric W. Biederman
2017-01-25  2:26         ` Eric W. Biederman
2017-01-25  2:28         ` Eric W. Biederman
2017-01-25  2:28           ` Eric W. Biederman
2017-01-25  3:50           ` Michael Kerrisk (man-pages)
2017-01-26  4:23             ` Eric W. Biederman [this message]
2017-01-26  4:23               ` Eric W. Biederman
     [not found]               ` <87a8aea1pp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-02-03  2:34                 ` Eric W. Biederman
2017-02-03  2:34                   ` Eric W. Biederman
     [not found]                   ` <87wpd82ear.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-02-08 14:13                     ` Michael Kerrisk (man-pages)
2017-02-08 14:13                       ` Michael Kerrisk (man-pages)
     [not found] ` <2c27a76e-336d-e2ad-4b30-22e29249c2e9@gmail.com>
     [not found]   ` <2c27a76e-336d-e2ad-4b30-22e29249c2e9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-25  1:03     ` [PATCH v4 1/2] nsfs: Add an ioctl() to return the namespace type Michael Kerrisk (man-pages)
2017-01-25  1:03       ` Michael Kerrisk (man-pages)
2017-01-25  1:04     ` [PATCH v4 2/2] nsfs: Add an ioctl() to return owner UID of a userns Michael Kerrisk (man-pages)
2017-01-25  1:04       ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a8aea1pp.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=avagin@openvz.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=serge@hallyn.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wking@tremily.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.