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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Apr 2007 18:21:26 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andreas Gruenbacher <agruen@...e.de>
Cc:	jjohansen@...e.de, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it
 unambiguous; exclude unreachable mount points from /proc/mounts

> 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.

The current state is not good either

> 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.

Can you prove no existing application on the planet relies on the
existing behaviour ? Actually more limited but sane as a test would be
"Can you prove that the glibc behaviour visible to applications does not
change"

> 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.

I disagree - firstly because of not breaking stuff, and secondly because
it separates two discussions - merging AppArmor being one of them , and
the correct behaviour for getcwd & /proc/mounts being the other.

> > 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?

Because the viewing apparatus on the other side of the monitor is not
operating in current directories/contexts.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/