[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k1rlkh1g.fsf@xmission.com>
Date: Tue, 29 May 2018 21:34:35 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Dave Chinner <david@...morbit.com>
Cc: "Theodore Y. Ts'o" <tytso@....edu>,
Linux Containers <containers@...ts.linux-foundation.org>,
linux-fsdevel@...r.kernel.org,
Seth Forshee <seth.forshee@...onical.com>,
"Serge E. Hallyn" <serge@...lyn.com>,
Christian Brauner <christian@...uner.io>,
linux-kernel@...r.kernel.org
Subject: Re: [REVIEW][PATCH 0/6] Wrapping up the vfs support for unprivileged mounts
Dave Chinner <david@...morbit.com> writes:
> Yeah, the are some fairly big process and policy things that need
> to be decided here. Not just at the kernel level, but at distro and
> app infrastructure level too.
>
> I was originally sceptical of supporting kernel filesystems via lkl,
> but the desire for unprivileged mounts has not gone away and so I'm
> less worried about accessing filesystems that way than I am of
> letting the kernel parse untrusted images from untrusted users...
There is also the more readily available libguestfs which doesn't
support as many filesystems but does seem available in most
linux distributions already. It already has a fuse option available
with guestmount. I may have to dig in there and see how to make
it available without using fusermount.
> I'm not sure what the correct forum for this is - wasn't this
> something the Plumbers conference was supposed to facilitate?
Yes. If we all need to be in a room and talk about things.
It is early enough in the planning for Plumers that we could
definitely schedule a talk or a BOF for this.
>> Is fusefs-lkl valuable for testing filesystems? If xfs-tests were to
>> have a mode that used that used the fuse protocol for testing and
>> fuzzing filesystems without the full weight of the kernel in the middle
>> that might encourage people to suppor this kind of things as well.
>
> Getting lkl-fuse to run under fstests would be a great way to ensure
> we have some level of confidence that it will do the right thing and
> users can expect that it won't eat their data. I think this would
> need to be a part of a recommendation for wider deploy of such a
> solution...
Good thought. I will have to give that a look. That does sound like a
good practical test.
Eric
Powered by blists - more mailing lists