From: ebiederm@xmission.com (Eric W. Biederman)
To: Seth Forshee <seth.forshee@canonical.com>
Cc: linux-fsdevel@vger.kernel.org,
"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Fix debugfs bind mount regression
Date: Wed, 09 Mar 2016 14:57:47 -0600 [thread overview]
Message-ID: <87oaanz7w4.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <1457536687-32794-1-git-send-email-seth.forshee@canonical.com> (Seth Forshee's message of "Wed, 9 Mar 2016 09:18:05 -0600")
Seth Forshee <seth.forshee@canonical.com> writes:
> Some full-OS container software bind mounts debugfs into containers to
> satisfy the assumptions of older userspaces which expect to be able to
> mount debugfs. This regressed in 4.1 due to the addition of tracefs,
> which gets automounted in the tracing subdirectory of debugfs. In a
> cloned mount namespace the bind mount now fails because the tracefs
> mount is a locked child of the debugfs mount.
>
> For new mounts we already make an exception to the "locked child mount"
> rule. Directories in psuedo filesystems created for the sole purpose of
> being mountpoints are created as permanently empty directories which can
> never contain any entries, therefore the kernel can know than any mounts
> on these directories are not for security purposes. These mounts are
> then excluded from locked mount tests in some circumstances.
>
> The same logic clearly applies to directories created in
> debugfs_create_automount(). The following patches update this function
> to create permanently empty directories for mountpoints and adds an
> exclusion to the tests for bind mounts to exclude child mounts on
> permanently empty directories.
So I don't know that this approach is bad. However in reading through
your patch descriptions I do not see any consideration of using
"mount --rbind" instead of "mount --bind". AKA adding the MS_REC flag
to your bind mount.
I would think simply using MS_REC would solve this problem, without
needing any additional kernel support. Am I missing something?
Eric
next prev parent reply other threads:[~2016-03-09 20:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 15:18 [PATCH 0/2] Fix debugfs bind mount regression Seth Forshee
2016-03-09 15:18 ` [PATCH 1/2] fs: Allow bind mounts with locked children on permaenetly empty directories Seth Forshee
2016-03-09 20:32 ` Serge E. Hallyn
2016-03-09 15:18 ` [PATCH 2/2] debugfs: Make automount point inodes permanently empty Seth Forshee
2016-03-09 20:32 ` Serge E. Hallyn
2016-03-09 20:57 ` Eric W. Biederman [this message]
2016-03-09 21:18 ` [PATCH 0/2] Fix debugfs bind mount regression Serge Hallyn
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=87oaanz7w4.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@ubuntu.com \
--cc=seth.forshee@canonical.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.