Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 13 Oct 2021 18:48:26 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Rob Landley <rob@landley.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: The one and only "permission denied" in find /sys
User-Agent: K-9 Mail for Android
In-Reply-To: <cd81a57e-e2c1-03c5-d0da-f898babf92e7@landley.net>
References: <cd81a57e-e2c1-03c5-d0da-f898babf92e7@landley.net>
Message-ID: <7042EFC5-DA90-4B9A-951A-036889FD89CA@chromium.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On October 13, 2021 1:12:16 PM PDT, Rob Landley <rob@landley=2Enet> wrote:
>There is exactly one directory in the whole of sysfs that a normal user c=
an't
>read (at least on my stock devuan laptop):
>
>  $ find /sys -name potato
>  find: =E2=80=98/sys/fs/pstore=E2=80=99: Permission denied
>
>It's the "pstore" filesystem, it was explicitly broken by commit d7caa336=
87ce,
>and the commit seems to say this was to fix an issue that didn't exist ye=
t but
>might someday=2E

Right, so, the problem did certainly exist: there was a capability check f=
or opening the files, which made it difficult for pstore collector tools to=
 run with sane least privileges=2E Adjusting the root directory was the sim=
plest way to keep the files secure by default, and allow a system owner the=
 ability to delegate collector permissions to a user or group via just a ch=
mod on the root directory=2E

>Did whatever issue it was concerned about ever actually start happening? =
Why did
>you not change the permissions on the files _in_ the directory so they we=
ren't
>world readable instead? Should /dev/shm stop being world ls-able as well?

Making the per-file permissions configurable at runtime was more complex f=
or little additional gain=2E

/dev/shm has the benefit of having an existing permission model for each c=
reated file=2E

I wouldn't be opposed to a mount option to specify the default file owner/=
group, but it makes user space plumbing more difficult (i=2Ee=2E last I che=
cked, stuff like systemd tends to just mount kernel filesystems without opt=
ions)=2E

-Kees

--=20
Kees Cook