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]

Message-ID: <m1ft20zw3j.fsf@fess.ebiederm.org>
Date:   Fri, 12 Feb 2021 17:48:16 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Joe Perches <joe@...ches.com>,
        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

Matthew Wilcox <willy@...radead.org> writes:

> On Fri, Feb 12, 2021 at 04:01:48PM -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.
>
> Heh, I'm the other way, I can't remember what S_IRUGO means.
>
> but I think there's another way which improves the information
> density:
>
> #define DIR_RO_ALL(NAME, iops, fops)	DIR(NAME, 0555, iops, fops)
> ...
> (or S_IRUGO or whatever expands to 0555)
>
> There's really only a few combinations --
> 	root read-only,
> 	everybody read-only
> 	root-write, others-read
> 	everybody-write
>
> and execute is only used by proc for directories, not files, so I think
> there's only 8 combinations we'd need (and everybody-write is almost
> unused ...)

I guess it depends on which part of proc.  For fs/proc/base.c and it's
per process relatives something like that seems reasonable.

I don't know about fs/proc/generic.c where everyone from all over the
kernel registers new proc entries.

>> Perhaps we can do something like:
>> 
>> #define S_IRWX 7
>> #define S_IRW_ 6
>> #define S_IR_X 5
>> #define S_IR__ 4
>> #define S_I_WX 3
>> #define S_I_W_ 2
>> #define S_I__X 1
>> #define S_I___ 0
>> 
>> #define MODE(TYPE, USER, GROUP, OTHER) \
>> 	(((S_IF##TYPE) << 9) | \
>>          ((S_I##USER)  << 6) | \
>>          ((S_I##GROUP) << 3) | \
>>          (S_I##OTHER))
>> 
>> Which would be used something like:
>> MODE(DIR, RWX, R_X, R_X)
>> MODE(REG, RWX, R__, R__)
>> 
>> Something like that should be able to address the readability while
>> still using symbolic constants.
>
> I think that's been proposed before.

I don't think it has ever been shot down.  Just no one care enough to
implement it.

Come to think of it, that has the nice property that if we cared we
could make it type safe as well.  Something we can't do with the octal
for obvious reasons.

Eric