Re: [PATCH v3 0/7] User namespace mount updates

[Octavian Purdila]

On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@xxxxxx> wrote:
> Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
>> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
>> <seth.forshee@xxxxxxxxxxxxx> wrote:
>>>
>>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>>>> <seth.forshee@xxxxxxxxxxxxx> wrote:
>>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>>>
>>>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>>>> haven't seen any public comments to that effect.
>>>>>>
>>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>>>
>>>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>>>> will be next.
>>>>
>>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>>>> What about just enabling fuse and implement ext4 and friends as fuse
>>>> filesystems?
>>>> Using the approaching Linux Kernel Libary[1] this is easy.
>>>
>>> I haven't looked at this project, but I'm guessing that programs must be
>>> written specifically to make use of it? I.e. you can't just use the
>>> mount syscall, and thus all existing software still doesn't work?
>>>
>>
>> The projects includes a lklfuse program that uses fuse to mount a
>> fileystem image.
>
> Cool. I gave it a try.
> It seems to work fine, but only if I run it in foreground (using -d)
> otherwise fuse blocks every filesystem request.
>

Now it should work in the background as well, thanks for reporting the issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/