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: <20140929193329.GL7996@ZenIV.linux.org.uk>
Date:	Mon, 29 Sep 2014 20:33:29 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Dmitry V. Levin" <ldv@...linux.org>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND v3 PATCH 3/3] vfs: make mounts and mountstats honor root
 dir like mountinfo does

On Mon, Sep 29, 2014 at 10:43:33PM +0400, Dmitry V. Levin wrote:
> On Mon, Sep 29, 2014 at 07:32:22PM +0100, Al Viro wrote:
> > On Mon, Sep 29, 2014 at 10:05:23PM +0400, Dmitry V. Levin wrote:
> > > Date: Wed, 17 Oct 2012 20:29:55 +0400
> > > 
> > > Change show_vfsmnt() and show_vfsstat() to show mountpoints relative
> > > to the root directory and skip mountpoints outside of chroot jail
> > > the same way as show_mountinfo() does.
> > 
> > Sigh...  Repeat after me:  We  Do  Not  Break  Userland.  Care to explain
> > why that change won't do just that?
> 
> This is definitely an information leak, and I cannot imagine how these
> unaccessible entries listed in /proc/self/mounts and /proc/self/mountstats
> could be used sanely.

How do you think any existing script running chrooted is going to parse
/proc/mounts?  One obvious way is to filter on known prefix and strip it
away.  With your change it will instantly break.  Moreover, any script
working with *new* semantics will break as soon as you boot an older
kernel.

Existing behaviour had been there since mid-90s (at least) and I'm absolutely
certain that such scripts do exist.  I know that, since I had to write such.
Again, we do not break userland.  Especially since the behaviour you want
is trivial to obtain - just create a new namespace instead of messing with
chroot.  Then, in that namespace, pivot_root the sucker to root and unmount
everything else.  Voila.

NAK.  And you really need to realize that changing ABI in a way that breaks
real-world userland code is not acceptable.  Even when the new semantics is
nicer.  And when you cannot imagine how somebody could possibly write code
that would depend on the old one.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ