Miklos Szeredi wrote:Yeah, ioctl, by design, has that potential. Whether it's implemented in kernel or userland, it's gonna access arbitrary memory regions from deep down the implementation, and it can corrupt things, but by giving the responsibility to move data to kernel part of FUSE, we can at least guarantee that it's only gonna ruin the calling address space even when it screws up and when that happens it will be easy to track down by tracing the communication between the kernel and FUSE client. I'm not worried about the client accessing wrong memory regions or even corrupting it. It's pointless to try to protect against that. From the calling process's POV, it runs the same risk whether it calls an in-kernel ioctl or a CUSE one and FUSE already has sufficient protection against allowing unprivileged FS implementation to serve other users. What I'm worried about is the possibility of CUSE client being able to break out of that privilege protection which is currently ensured by the kernel. Also, what about containers? How would it work then? Thanks. -- tejun --
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Nick Piggin | [patch 3/6] mm: fix fault vs invalidate race for linear mappings |
| Stefan Richter | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| Ingo Molnar | [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
git: | |
| Peter Zijlstra | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Doug Evans | Re: Stabilizing Linux |
| Robert Blum | And another version of the INFO sheet |
| Marc CORSINI | find-1.2 (binaries only) |
| Yanek Martinson | Re: Porting g++ 1.40.3 |
