On Thu, Sep 29, 2022 at 07:50:36PM +0100, Al Viro wrote:
> > https://lore.kernel.org/all/CADDKRnDD_W5yJLo2otWXH8oEgmGdMP0N_p7wenBQbh17xKGZJg@mail.gmail.com/
> >
> > in case anybody cares.
> >
> > I wonder if the fix is to replace the symlink with a hardcoded lookup
> > (ie basically make it *act* like a hardlink - we don't really support
> > hardlinked directories, but we could basically fake the lookup in
> > proc). Since the problem was AppArmor reacting to the name in the
> > symlink.
> >
> > Al added the participants so that he can say "hell no".
>
> What do you mean? Lookup on "net" in /proc returning what, exactly?
> What would that dentry have for ->d_parent?
Looking at that thread, it seems that <censored> "policy" would not be
satisfied with anything other than /proc/*/task/*/net being seen
as /proc/<something>/net. As in "cd there and /bin/pwd will tell you
tha you are in /proc/<some number>/net".
Which is insane, especially since the entire problem is due to wanting
that directory to be different for different threads...
On Thu, Sep 29, 2022 at 12:00 PM Al Viro <[email protected]> wrote:
>
> Which is insane, especially since the entire problem is due to wanting
> that directory to be different for different threads...
Absolutely. This is all due to Apparmor (a) basing things on pathnames
and (b) then getting those pathnames wrong.
Which is why I'm just suggesting we short-circuit the path-name part,
and not make this be a real symlink that actually walks a real path.
The proc <pid> handling uses "readlink" to make it *look* like a
symlink, but then "get_link" to actually look it up (and never walk it
as a path).
Something similar?
Linus