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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 29 May 2014 13:20:49 +0200 From: Seth Forshee <seth.forshee@...onical.com> To: "H. Peter Anvin" <hpa@...or.com> Cc: linux-kernel@...r.kernel.org, lxc-devel@...ts.linuxcontainers.org, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Alexander Viro <viro@...iv.linux.org.uk>, James Bottomley <James.Bottomley@...senPartnership.com>, Serge Hallyn <serge.hallyn@...ntu.com>, "Michael H. Warfield" <mhw@...tsend.com>, Marian Marinov <mm@...com>, Eric Biederman <ebiederm@...ssion.com>, Richard Weinberger <richard.weinberger@...il.com>, Andy Lutomirski <luto@...capital.net>, Michael J Coss <michael.coss@...atel-lucent.com> Subject: Re: [RFC PATCH 0/2] Loop device psuedo filesystem On Wed, May 28, 2014 at 04:47:24PM -0700, H. Peter Anvin wrote: > On 05/27/2014 02:58 PM, Seth Forshee wrote: > > > > 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. > > > > May I instead strongly advocate a slightly different solution: leave > legacy loop devices where they are, with the current semantics, and let > them be. Make the loopfs loop devices completely independent. Consider > this equivalent of Unix98 ptys versus legacy BSD ptys. > > Then, hopefully, use of the legacy ones will disappear over time. > Enabling the new ones in losetup and friends is simple enough; this is > not like ptys where the old scheme was hard-coded into a hundred > different applications. I'm not really sure what you're thinking should be changed about the loop driver. Sure, I can think of a few things I'd change, but nothing intractable. If it's the semantics, I'm not really changing those in any significant way. Today losetup opens /dev/loop-control and asks for a free device, and it receives either an existing, unused device or a new device which appears at /dev/loopN. All that changes here is that it would need to try /dev/loop/loop-control as well, and devices would appear at /dev/loop/N (which is a convention losetup already understands, it just needs to look there in some cases where it doesn't currently). Or perhaps you're suggesting a more radical change to the semantics? Thanks, Seth -- 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