Messages in this thread | | | Subject | Re: [PATCH 5/7] FUSE: implement ioctl support | From | Miklos Szeredi <> | Date | Mon, 01 Sep 2008 13:57:58 +0200 |
| |
On Fri, 29 Aug 2008, ebiederm@xmission.com (Eric W. Biederman) > Tejun Heo <tj@kernel.org> writes: > > The FUSE server gets task->pid. IIUC, if the FUSE server is not in a > > container, task->pid should work fine whether the caller is in > > container or not, right? And if the FUSE server is in a container, > > it's hell lot more complex and FUSE may have to map task->pid to what > > FUSE server would know if possible? > > Implementation wise it is not too bad. > > FUSE ---------------- > pid = get_pid(task_tid(current)) > ^ | > | | kernel > pid_vnr(pid)
Ahh, thanks. I'll need to fix this up then, regardless of any ioctl issues, so that the tid supplied to the userspace filesystem actually makes sense in a containerized environment.
> However it is a largely an insane idea. > - Write is not implemented for /proc/PID/task/TID/mem
Mmm, that does pose a bit of a problem :)
> - It would be better if the kernel handed you back a file descriptor > to the other process memory rather than you having to generate one.
Yep, that could be done...
> - To access /proc/PID/task/TID/mem you need to have CAP_PTRACE.
Yes, but access to the other process's address space requires some sort of privilege anyway. It would not do to have an unprivileged process peek at arbitrary addresses in the other process's memory, and that is exactly what generic ioctl support requires.
> - This seems to allow for random ioctls. With the compat_ioctl > thing we have largely stomped on that idea. So you should only need > to deal with well defined ioctls. At which point why do you need to > directly access the memory of another process. > > So why not just only support well defined ioctls and serialize them > in the kernel and allow the receiving process to deserialize them?
I'd like the idea of limiting to well behaved ioctls, but Tejun doesn't...
> That would allow all of this to happen with a non-privileged server > which makes the functionality much more useful.
There's still a security issue, because we cannot verify *if* a particular ioctl is indeed well behaved: only the application and the driver knows that, and the application cannot tell us (ioctl interface is broken, broken, broken), and we don't trust the server.
Thanks, Miklos
| |