linux-kernel - Re: [PATCH -next 0/3] sysvipc: introduce STAT

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Feb 2018 14:09:11 -0800
From:   Davidlohr Bueso <dave@...olabs.net>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     akpm@...ux-foundation.org, mhocko@...nel.org,
        mtk.manpages@...il.com, keescook@...omium.org,
        linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

On Tue, 13 Feb 2018, Eric W. Biederman wrote:

>Davidlohr Bueso <dave@...olabs.net> writes:
>
>> Hi,
>>
>> The following patches adds the discussed[1] new command for shm
>> as well as for sems and msq as they are subject to the same discrepancies
>> for ipc object permission checks between the syscall and via procfs.
>> These new commands are justified in that (1) we are stuck with this
>> semantics as changing syscall and procfs can break userland; and (2) some
>> users can benefit from performance (for large amounts of shm segments,
>> for example) from not having to parse the procfs interface.
>>
>> Once (if) merged, I will submit the necesary manpage updates. But I'm
>> thinking something like:
>
>I am just going to kibitz for a moment.

Nice word that, kibitz.

>
>Could we name this _STAT_ANY or _STAT_NOPERM instead of _STAT_ALL.
>
>I keep thinking a name with _ALL in it should affect all ipc opbjects of
>a given type, not simply work any ipc object regardless of permissions.

Yeah, and _ALL similarly makes the difference of IPC_STAT and SHM_STAT wrt
the passed shmid that more adhoc.

I'm going to go with _STAT_ANY.

Thanks,
Davidlohr