linux-kernel - Re: [d_path 0/7] Fixes to d

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]

Message-Id: <E1Hezy0-0001Pf-00@dorka.pomaz.szeredi.hu>
Date:	Fri, 20 Apr 2007 22:44:28 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	drepper@...il.com
CC:	agruen@...e.de, alan@...rguk.ukuu.org.uk, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	akpm@...ux-foundation.org
Subject: Re: [d_path 0/7] Fixes to d_path: Respin

> > I gave a chroot example that showed that in the current
> > implementation, you can get pretty random clashes between mounts; there are
> > other cases with lazy unmounts as well.
> 
> Irrelevant as well.  If you create chroot problems it's your problem.
> 
> The fact is that if you have a normal setup the code works fine.  All
> other situations cannot be handled with the current kernel interface.
> 
> This does not give anybody the right to say "since the code doesn't
> always work we can break it completely".  That's completely
> unacceptable.

I'm not sure I understand the situation completely.  What exactly is
broken in libc by removing unreachable mounts from /proc/mounts?

Is it the situation when
 - file descriptor is opened
 - process does chroot
 - process does fstatvfs on file descriptor
?

In that case currently fstatvfs() _usually_ gives the correct results,
but can give wrong results if mounts paths accidently clash in
/proc/mounts?

Also isn't it the case, that fstatvfs() or statvfs() performed within
the chroot could also give incorrect result for a _reachable_ mount if
it clashes with an unreachable mount?

If this is the case, I would think that removing the unreachable
mounts from /proc/mounts, would actually be fixing this second case,
which is more likely to be used anyway.

BTW, this patch, or at least a predecessor is in -mm, and it very much
feels the Right Thing(tm).  The /proc/mounts under a chroot
environment actually looks sane, instead of some random crap, that it
was previously.

While we should make every effort to keep the kernel interfaces
stable, this shouldn't prevent us from fixing bugs.  And this one is
clearly a bug, even if not a very serious one.

Miklos
-
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/