Re: FUSE merging?

[Miklos Szeredi <miklos@szeredi.hu>]

> However, a few things:
> 
> - is there anything in the current implementation of the permission stuff
>   which might tie our hands if it is later reimplemented?  IOW: does the
>   current FUSE user interface in any way lock us into the current FUSE
>   implementation (fuse_allow_task())?

No.  This thing is above the userspace interface and completely
independent.  Either a task is allowed, and then the request goes
through to the interface.  Or if it's not, the request is stopped
right there, and never reaches the userspace interface.

> - the fuse mount options don't seem to be documented

True.  I'll send a patch (they are documented in the README of the
fuse distribution).

> - aren't we going to remove the nfs semi-server feature?

I leave the decision to you ;)  It's a separate independent patch
already (fuse-nfs-export.patch).

> - Frank points out that a user can send a sigstop to his own setuid(0)
>   task and he intimates that this could cause DoS problems with FUSE.  More
>   details needed please?

Will follow up in Franks answer.

> - I don't recall seeing an exhaustive investigation of how an
>   unprivileged user could use a FUSE mount to implement DoS attacks against
>   other users or against root.

Here's a description of a theoretical DoS scenario:

  http://marc.theaimsgroup.com/?l=linux-fsdevel&m=111522019516694&w=2

Miklos

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/