From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul@paul-moore.com>, Munehisa Kamata <kamatam@amazon.com>
Cc: adobriyan@gmail.com, akpm@linux-foundation.org,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: Fw: [PATCH] proc: Update inode upon changing task security attribute
Date: Fri, 8 Dec 2023 15:21:12 -0800 [thread overview]
Message-ID: <0c0e8960-9221-43f0-a5d4-07c8f5342af0@schaufler-ca.com> (raw)
In-Reply-To: <CAHC9VhRRdaUWYP3S91D6MrD8xBMR+zYB3SpGKV+60YkmLwr7Sg@mail.gmail.com>
On 12/8/2023 2:43 PM, Paul Moore wrote:
> On Thu, Dec 7, 2023 at 9:14 PM Munehisa Kamata <kamatam@amazon.com> wrote:
>> On Tue, 2023-12-05 14:21:51 -0800, Paul Moore wrote:
> ..
>
>>> I think my thoughts are neatly summarized by Andrew's "yuk!" comment
>>> at the top. However, before we go too much further on this, can we
>>> get clarification that Casey was able to reproduce this on a stock
>>> upstream kernel? Last I read in the other thread Casey wasn't seeing
>>> this problem on Linux v6.5.
>>>
>>> However, for the moment I'm going to assume this is a real problem, is
>>> there some reason why the existing pid_revalidate() code is not being
>>> called in the bind mount case? From what I can see in the original
>>> problem report, the path walk seems to work okay when the file is
>>> accessed directly from /proc, but fails when done on the bind mount.
>>> Is there some problem with revalidating dentrys on bind mounts?
>> Hi Paul,
>>
>> https://lkml.kernel.org/linux-fsdevel/20090608201745.GO8633@ZenIV.linux.org.uk/
>>
>> After reading this thread, I have doubt about solving this in VFS.
>> Honestly, however, I'm not sure if it's entirely relevant today.
> Have you tried simply mounting proc a second time instead of using a bind mount?
>
> % mount -t proc non /new/location/for/proc
>
> I ask because from your description it appears that proc does the
> right thing with respect to revalidation, it only becomes an issue
> when accessing proc through a bind mount. Or did I misunderstand the
> problem?
It's not hard to make the problem go away by performing some simple
action. I was unable to reproduce the problem initially because I
checked the Smack label on the bind mounted proc entry before doing
the cat of it. The problem shows up if nothing happens to update the
inode.
next prev parent reply other threads:[~2023-12-08 23:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231129171122.0171313079ea3afa84762d90@linux-foundation.org>
2023-12-01 9:30 ` Fw: [PATCH] proc: Update inode upon changing task security attribute Alexey Dobriyan
2023-12-01 20:59 ` Munehisa Kamata
2023-12-01 21:42 ` Casey Schaufler
2023-12-05 22:21 ` Paul Moore
2023-12-05 22:31 ` Casey Schaufler
2023-12-08 2:14 ` Munehisa Kamata
2023-12-08 22:43 ` Paul Moore
2023-12-08 23:21 ` Casey Schaufler [this message]
2023-12-08 23:32 ` Paul Moore
2023-12-09 0:24 ` Casey Schaufler
2023-12-09 1:10 ` Munehisa Kamata
2023-12-09 18:10 ` Paul Moore
2023-12-09 21:17 ` Munehisa Kamata
2023-12-10 21:52 ` Paul Moore
2023-12-10 14:45 ` Serge E. Hallyn
2023-12-11 19:27 ` Munehisa Kamata
2023-12-11 19:49 ` Serge E. Hallyn
2023-12-09 18:08 ` Paul Moore
2023-12-09 18:35 ` Casey Schaufler
2023-12-09 22:44 ` Munehisa Kamata
2023-12-10 21:45 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c0e8960-9221-43f0-a5d4-07c8f5342af0@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=kamatam@amazon.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox