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. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
