linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: linux-kernel@vger.kernel.org, lxc-devel@lists.linuxcontainers.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	"Michael H. Warfield" <mhw@wittsend.com>,
	Marian Marinov <mm@1h.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Richard Weinberger <richard.weinberger@gmail.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Michael J Coss <michael.coss@alcatel-lucent.com>,
	Seth Forshee <seth.forshee@canonical.com>
Subject: [RFC PATCH 0/2] Loop device psuedo filesystem
Date: Tue, 27 May 2014 23:58:54 +0200	[thread overview]
Message-ID: <1401227936-15698-1-git-send-email-seth.forshee@canonical.com> (raw)

I'm posting these patches in response to the ongoing discussion of loop
devices in containers at [1].

The patches implement a psuedo filesystem for loop devices, which will
allow use of loop devices in containters using standard utilities. Under
normal use a loopfs mount will initially contain a single device node
for loop-control which can be used to request and release loop devices.
Any devices allocated via this node will automatically appear in that
loopfs mount (and in devtmpfs) but not in any other loopfs mounts.
CAP_SYS_ADMIN in the userns of the process which performed the mount is
allowed to perform privileged loop ioctls on these devices.

Alternately loopfs can be mounted with the hostmount option, intended
for mounting /dev/loop in the host. This is the default mount for any
devices not created via loop-control in a loopfs mount (e.g. devices
created during driver init, devices created via /dev/loop-control, etc).
This is only available to system-wide CAP_SYS_ADMIN.

I still have some testing to do on these patches, but they work at
minimum for simple use cases. It's possible to use an unmodified losetup
if it's new enough to know about loop-control, with a couple of caveats:

 * /dev/loop-control must be symlinked to /dev/loop/loop-control
 * In some cases losetup attempts to use /dev/loopN when the device node
   is at /dev/loop/N. For example, 'losetup -f disk.img' fails.

Device nodes for loop partitions are not created in loopfs. These
devices are created by the generic block layer, and the loop driver has
no way of knowing when they are created, so some kind of hook into the
driver will be needed to support this.

Thanks,
Seth

[1] http://article.gmane.org/gmane.linux.kernel/1703988

Seth Forshee (2):
  loop: Add loop filesystem
  loop: Permit priveleged operations within user namespaces

 drivers/block/loop.c       | 137 +++++++++++++----
 drivers/block/loop.h       |   2 +
 fs/Makefile                |   1 +
 fs/loopfs/Makefile         |   6 +
 fs/loopfs/inode.c          | 360 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/loopfs.h     |  53 +++++++
 include/uapi/linux/magic.h |   1 +
 7 files changed, 535 insertions(+), 25 deletions(-)
 create mode 100644 fs/loopfs/Makefile
 create mode 100644 fs/loopfs/inode.c
 create mode 100644 include/linux/loopfs.h


             reply	other threads:[~2014-05-27 21:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27 21:58 Seth Forshee [this message]
2014-05-27 21:58 ` [RFC PATCH 1/2] loop: Add loop filesystem Seth Forshee
2014-05-27 22:56   ` Randy Dunlap
2014-05-28  7:36     ` Seth Forshee
2014-05-27 21:58 ` [RFC PATCH 2/2] loop: Permit priveleged operations within user namespaces Seth Forshee
2014-05-27 22:19 ` [RFC PATCH 0/2] Loop device psuedo filesystem Andy Lutomirski
2014-05-28  7:32   ` Seth Forshee
2014-05-28 16:10     ` Andy Lutomirski
2014-05-28 17:39       ` Michael H. Warfield
2014-05-28 23:47 ` H. Peter Anvin
2014-05-29 11:20   ` Seth Forshee
2014-09-15 20:38 ` Shea Levy
2014-09-15 20:55   ` Seth Forshee
2014-09-15 23:20     ` Shea Levy
2014-09-16 12:24       ` Seth Forshee
2014-09-16 16:12       ` Shea Levy
2014-09-16 16:39         ` Seth Forshee
2014-09-16 17:05           ` Shea Levy
2014-09-16 17:26             ` Seth Forshee

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=1401227936-15698-1-git-send-email-seth.forshee@canonical.com \
    --to=seth.forshee@canonical.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=lxc-devel@lists.linuxcontainers.org \
    --cc=mhw@wittsend.com \
    --cc=michael.coss@alcatel-lucent.com \
    --cc=mm@1h.com \
    --cc=richard.weinberger@gmail.com \
    --cc=serge.hallyn@ubuntu.com \
    --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).