From: "Dmitry V. Levin" <ldv@altlinux.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND v3 PATCH 3/3] vfs: make mounts and mountstats honor root dir like mountinfo does
Date: Tue, 30 Sep 2014 00:26:59 +0400 [thread overview]
Message-ID: <20140929202659.GA16292@altlinux.org> (raw)
In-Reply-To: <20140929193329.GL7996@ZenIV.linux.org.uk>
On Mon, Sep 29, 2014 at 08:33:29PM +0100, Al Viro wrote:
> 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.
If a script relies on this behaviour, it is likely to be broken already
because the kernel strips chroot prefix somehow (I've just checked back to
2.6.32). The main purpose of this patch is to exclude from listing those
mount points that do not belong to the chroot at all.
> 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.
I'm very curious, what could your scripts do with paths outside chroot,
assuming that prefix removal was done by the kernel?
> Again, we do not break userland.
Occasionally, we do. If you say there was no chroot prefix removal in the
kernel before, and there seems to be a prefix removal for at least 5 years,
then there must have been a break some years ago that went unnoticed.
--
ldv
next prev parent reply other threads:[~2014-09-29 20:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 18:05 [RESEND v3 PATCH 3/3] vfs: make mounts and mountstats honor root dir like mountinfo does Dmitry V. Levin
2014-09-29 18:32 ` Al Viro
2014-09-29 18:43 ` Dmitry V. Levin
2014-09-29 19:33 ` Al Viro
2014-09-29 20:26 ` Dmitry V. Levin [this message]
2014-09-29 21:20 ` Al Viro
2014-09-29 22:56 ` Dmitry V. Levin
2014-12-16 3:59 ` [RESEND v4 PATCH 1/2] vfs: cleanup show_mountinfo Dmitry V. Levin
2014-12-16 3:59 ` [RESEND v4 PATCH 2/2] vfs: make mounts and mountstats honor root dir like mountinfo does Dmitry V. Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140929202659.GA16292@altlinux.org \
--to=ldv@altlinux.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).