Re: [PATCH v4 0/2] Add further ioctl() operations for namespace discovery

ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) writes:

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

On 25 January 2017 at 15:28, Eric W. Biederman [off-list ref] wrote:

quoted

quoted

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.

So I have just reverted the EOVERFLOW change, applied the patches to
my tree and pushed this to for-next.  Otherwise this looks like this
effort will have stalled.

Eric