Re: Fw: [PATCH] proc: Update inode upon changing task security attribute

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 8, 2023 at 6:21 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 12/8/2023 2:43 PM, Paul Moore wrote:
> > On Thu, Dec 7, 2023 at 9:14 PM Munehisa Kamata <kamatam@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx/
> >>
> >> 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.

A good point.

I'm kinda thinking we just leave things as-is, especially since the
proposed fix isn't something anyone is really excited about.

-- 
paul-moore.com





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux