Tejun Heo wrote:

quoted text
>> I still got qualms about this ioctl thing.  One is the security

>> aspect, but that could be dealt with.  The other is that I really

>> really don't want people to start implementing new custom ioctls for

>> their filesystems, as I think that way lies madness.  We could limit

>> ioctls to CUSE and that would be fine with me.  Or for non-CUSE users

>> we could enforce the "standard" format where the type and length is

>> encoded in the command number.

>

> For now, I'll limit ioctl to CUSE.  Hmmm... Yeah, limiting ioctl to

> well-formatted ones sounds like a good idea.

>

>> I don't have any problems with the iterative way you implemented

>> ioctls.  We just need some additional restrictions to the current

>> implementation, I think.

I've been thinking about this a bit more.  What do you think about

putting the following restrictions?
1. FUSE server can only support well-formed ioctls.  At the kernel side,

the interfaces remains the same for both FUSE and CUSE but libfuse only

exports well-formed ioctl API.
2. ioctl can only be used by FUSE server running as root (would this be

necessary?  I'm not sure.  To me it seems all the necessary protections

are already there).
Thanks.
--

tejun

--

unsubscribe notice
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/