[Openstack] [OSSA 2012-011] Compute node filesystem injection/corruption (CVE-2012-3447)

Matt Joyce matt.joyce at cloudscaling.com
Tue Aug 14 20:41:31 UTC 2012


I get what you are saying.  And for the sake of compatibility with other
clouds and their images obviously that's the way to go, but my inner nerd
is screaming "Well, about that... " and wanting me to rally people to the
idea of putting the logic inside the images rather than inside of the
cloud.   Let init negotiate the api access and produce the filesystems it
needs to get booted up properly.

=/  first world problems.

On Tue, Aug 14, 2012 at 12:06 PM, Eric Windisch <eric at cloudscaling.com>wrote:

> On Tuesday, August 14, 2012 at 14:30 PM, Matt Joyce wrote:
>
> I have to ask.  Wasn't FUSE designed to do alot of this stuff?  It is
> userspace and it doesn't do nasty stuff to file systems.  Why aren't we
> going that route?
>
> Fuse was really designed for the opposite scenario. Fuse "modules" run as
> daemons, they're not libraries.  These daemons attach to a character device
> and map userspace code into the VFS.  Instead, we want to access a
> filesystem from userspace code.  It is a shame, however, because you're
> right… there is plenty of code there that knows how to read filesystems in
> userspace.  Unfortunately, the FUSE design really doesn't do us any favors.
>
> That said, there are some crazy options to fix that. One could
> theoretically replace the FUSE character device with one that spoke to
> userspace processes, instead of interacting with the VFS.  There has even
> been work into creating user-space character devices.  One could also make
> FUSE work with Unix sockets as an alternative to character devices…
>
> None of this is out of the box, tested, or even in existence...
>
> Regards,
> Eric Windisch
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120814/5a9ea096/attachment.html>


More information about the Openstack mailing list