Miklos Szeredi wrote:

quoted text
>> Well, it's only 240 lines with good amount of comments and iovec copying

>> function.  The ioctl itself isn't too complex.  I'm a bit skeptical

>> about direct access.  It can easily introduce security vulnerabilities

>> as there really is no way to hold a pid.

>

> I don't understand.  No new vulnerabilities are introduced, since it

> would just use existing infrastructure.

>

> Why is it better if the kernel does the copying of memory regions

> instructed by the userspace filesystem, than if the userspace

> filesystem does that copying itself?  I feel they are totally

> equivalent, except that the latter needs more complexity in the

> kernel.

I'm no security expert but it feels pretty dangerous to me.  First of

all, there are cases where the calling process can exit before the

userland FUSE is finished with an operation, so it might not be always

possible for the FUSE client to tell the PID it got is the correct one.
Another thing is that as it currently stands, the kernel side FUSE

implementation forms a nice safety net taking responsibility of most

security concerns and insulating the mistakes the client may make.

Letting userland client to access and possibly modify the caller's

memory directly weakens that insulation.
Pushing memory access to userland feels a bit too risky to me.  There

seem to be too many loose components in security sensitive path and I

have a nagging feeling that someone will come up with something we can't

think of at the moment.
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/