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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 8 Feb 2017 15:13:10 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Linux API <linux-api@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Andrey Vagin <avagin@...nvz.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        "W. Trevor King" <wking@...mily.us>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v4 0/2] Add further ioctl() operations for namespace discovery

Hi Eric,

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