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
Hi Eric,
On 3 February 2017 at 03:34, Eric W. Biederman [off-list ref] wrote:
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) writes:
quoted
"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.
Sorry for not following up earlier. I got a bit distracted and wanted
to make some time to further reflect on which approach was better, and
reconsider my example code. Reverting the EOVERFLOW piece seems best
to me. Thanks for applying.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/