On Fri, 29 Aug 2008, ebiederm@xmission.com (Eric W. Biederman)
quoted text
> 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.

quoted text
> 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 :)

quoted text
> - 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...

quoted text
> - 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.

quoted text
> - 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...

quoted text
> 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
--
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/