linux-kernel - Re: [PATCH] proc: Convert S_<FOO> permission uses to octal

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:   Fri, 12 Feb 2021 17:44:16 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Joe Perches <joe@...ches.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] proc: Convert S_<FOO> permission uses to octal

Joe Perches <joe@...ches.com> writes:

> On Fri, 2021-02-12 at 16:01 -0600, Eric W. Biederman wrote:
>> Joe Perches <joe@...ches.com> writes:
>> 
>> > Convert S_<FOO> permissions to the more readable octal.
>> > 
>> > Done using:
>> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=SYMBOLIC_PERMS fs/proc/*.[ch]
>> > 
>> > No difference in generated .o files allyesconfig x86-64
>> > 
>> > Link:
>> > https://lore.kernel.org/lkml/CA+55aFw5v23T-zvDZp-MmD_EYxF8WbafwwB59934FV7g21uMGQ@mail.gmail.com/
>> 
>> 
>> I will be frank.  I don't know what 0644 means.  I can never remember
>> which bit is read, write or execute.  So I like symbolic constants.
>> 
>> I don't see a compelling reason to change the existing code.
>
> Did you read Linus' message in the Link: above?
>
> It was a reply to what Ingo Molnar suggested here:
>
> https://lore.kernel.org/lkml/20160803081140.GA7833@gmail.com/

Only if you read in reverse chronological order.

Ingo's message was in reply to Linus and it received somewhat favorable
replies and was not shot down.

I certainly do not see sufficient consensus to go around changing code
other people maintain.

My suggest has the nice property that it handles all 512 different
combinations.  I think that was the only real downside of Ingo's
suggestion.  There are just too many different combinations to define
a set of macros to cover all of the cases.

Eric