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
| ||
|
Date: Wed, 28 May 2014 16:47:24 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Seth Forshee <seth.forshee@...onical.com>, linux-kernel@...r.kernel.org, lxc-devel@...ts.linuxcontainers.org CC: 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 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. -hpa -- 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