Re: RFC: /dev/stdin, symlinks & permissions

From: H. Peter Anvin
Date: Sun Mar 23 2008 - 12:51:45 EST


Theodore Tso wrote:

Maybe our mistake was to make /dev/fd a symlink to /proc/self/fd, and
/dev/stdin a symlink to /proc/self/fd/0, et. al, since we don't get
the semantics exactly right compard to other operating systems.


No, our mistake was doing broken semantics and thinking they were good enough.

1.2 tried to mix both. I'm not actually sure that it was a good idea wrt
security, while we are at it...

What is the security problem that you are worried about? That it
might leak the pathname to someone who had an open file handle to the
file? That doesn't seem like a huge deal to me....

We could implement Plan 9 style dupfs, but to do that without excessive
ugliness we'd need to change prototype of ->open() - it must be able to
return a reference to struct file different from anything it got from
caller; probably the least painful way would be to make it return
NULL => success, use struct file passed to ->open()
ERR_PTR(-err) => error
pointer to struct file => success, caller should drop the
reference to struct file it had passed to ->open() and use the return value.
Still a mind-boggling amount of churn - probably too much to bother with.

Yeah, ouch. The only other way to do it would be to add a new
function pointer to the file_operations() field which would only be
used filled in by procfs inodes, and then have the sys_open() routine
call that function pointer if open() was zero. But that would be
quite ugly....


There is, at least theoretically speaking, another reason to do this: it would allow a device driver that makes userspace upcalls a much cleaner way to say "you really want this thing over there" by simply opening in userspace and passing down the file descriptor.

My suggestion for how to implement this would be to librarize the allocation of a new file structure, and make it a new ->alloc_open() method. The default implementation of ->alloc_open() would be (VERY VERY simplified, obviously):

alloc_open(inode)
{
struct file *file = allocate_new_file();
inode->ops->open(file);
return file;
}

-hpa
--
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/