public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Theodore Tso <tytso@mit.edu>, Al Viro <viro@ZenIV.linux.org.uk>,
	Michael Tokarev <mjt@tls.msk.ru>, Andreas Schwab <schwab@suse.de>,
	Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RFC: /dev/stdin, symlinks & permissions
Date: Sun, 23 Mar 2008 09:50:21 -0700	[thread overview]
Message-ID: <47E68A4D.7010706@zytor.com> (raw)
In-Reply-To: <20080318150439.GB27000@mit.edu>

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

  reply	other threads:[~2008-03-23 16:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-17 23:26 RFC: /dev/stdin, symlinks & permissions Michael Tokarev
2008-03-17 23:54 ` Andreas Schwab
2008-03-18  7:24   ` Michael Tokarev
2008-03-18 12:54     ` Theodore Tso
2008-03-18 14:32       ` Al Viro
2008-03-18 15:04         ` Theodore Tso
2008-03-23 16:50           ` H. Peter Anvin [this message]
2008-03-23  4:35         ` Denys Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47E68A4D.7010706@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=schwab@suse.de \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox