Re: [PATCH 5/7] FUSE: implement ioctl support

[Miklos Szeredi]

On Fri, 29 Aug 2008, ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
> Tejun Heo <tj@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/