Hi Eric, On 3 February 2017 at 03:34, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > >> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >> >> >>> On 25 January 2017 at 15:28, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> 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. > > 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/
