Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

Andreas Gruenbacher
2007-04-17T01:35:26Z

On Monday 16 April 2007 23:57, Alan Cox wrote:
> I don't believe the existing behaviour _IS_ a mistake.

So what would be the arguments why this behavior makes sense, other than
legacy?

For /proc/mounts, one could argue that the admin might want to see everything,
but then that's not actually true even today because /proc/mounts doesn't
show lazyily unmounted stuff or mounts from other namespaces, so that
everything is quite relative.

Along that line of argumentation, I would at least expect unambiguous output,
to be able to tell which mountpoints are actually meaningful to the
requesting process. It's not only human operators looking at /proc/mounts;
applications care as well.

But after thinking about this issue quite a while, I really can't see what
that should be good for. The current /proc/mounts interface is obviously
broken; the chroot example should have demonstrated that. There are also
unnecessary special cases because of that, such as having to filter out the
rootfs entry when trying to figure out what's really mounted on /, and having
to guess what's there and what's not in a particular context. The more
complex mount scenarios will get, the more obviously broken the
current /proc/mounts interface will become.

The getcwd() case is even stronger as the "see everything" argument makes even
less sense there. I really can't see why the kernel should return processes
fake pathnames. The process is explicitly asking for the current pathname to
the working directory, it doesn't want to know what the pathname was at some
previous point in time.

> > Process can access file descriptors which are unreachable via path name
> > just fine indeed, but those fds still don't have a valid path in the
> > context of that process.
>
> Which while problematic to your name based security is just fine to
> everything else.

Actually, no. We could live fine with leaving getcwd() and /proc/mounts as
ambiguous / weird / broken as they are right now. All it would take would be
to reambiguate the result of the unambiguous __d_path(), which is really
easy. Everything that cares about real pathnames would use the unambiguous
version while the legacy interfaces would use the ambiguous version. But that
really wouldn't make sense.

> Ok, providing the "real" root sees them all it isn't so bad, but to
> assume you can filter based upon what the task can see is dodgy as an
> assumption.

Why?

Thanks,
Andreas