From: Andy Lutomirski <luto@mit.edu>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] vfs: new O_NODE open flag
Date: Sat, 05 Dec 2009 09:42:33 -0500 [thread overview]
Message-ID: <4B1A7159.3070101@mit.edu> (raw)
In-Reply-To: <E1NG4WJ-00026r-GE@pomaz-ex.szeredi.hu>
Miklos Szeredi wrote:
> On Wed, 2 Dec 2009, Alan Cox wrote:
>>> You're still missing the point. O_NODE is like a hard link, except
>>> the reference doesn't come from the filesystem but from a file
>>> descriptor. From udev's perspective there's no difference.
>> I don't think I am missing the point here. You have a reference to an
>> object in the fs but you don't have a reference to the driver underneath
>> s the driver can change on you *while* you have the O_NODE open and fd
>> live. That cannot happen with a hard link and open.
>>
>> It isn't the same thing as far as I can see. You don't have the barrier
>> between the operations that occurs in the real open/close case because
>> they lock the driver.
>
> The file descriptor opened with O_NODE allows exaclactly the same
> operations that a hard link to the device would, nothing more. It's
> just a link to the *node*, except it doesn't increment the link count,
> the driver is irrelevant.
>
I don't know what that means. Do you mean that if:
root creates /dev/foo with 0666 perms
eviluser opens /dev/foo with O_NODE
root chmods /dev/foo to 0000
root unlinks /dev/foo
then eviluser can't open /proc/self/fd/whatever for O_RDRW
Because if eviluser could still open /proc/self/fd/whatever for O_RDRW
(or anything else for that matter if O_NODE isn't set) then you have a
security problem.
--Andy
next prev parent reply other threads:[~2009-12-05 14:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-02 16:16 [PATCH v3] vfs: new O_NODE open flag Miklos Szeredi
2009-12-02 19:15 ` Alan Cox
2009-12-02 20:13 ` Miklos Szeredi
2009-12-02 20:48 ` Alan Cox
2009-12-03 5:46 ` Miklos Szeredi
2009-12-05 14:42 ` Andy Lutomirski [this message]
2009-12-05 19:40 ` Miklos Szeredi
2009-12-05 20:28 ` Alan Cox
2009-12-05 20:35 ` Miklos Szeredi
2009-12-05 23:13 ` Alan Cox
2009-12-07 6:08 ` Miklos Szeredi
2009-12-07 12:23 ` Alan Cox
2009-12-07 12:41 ` Miklos Szeredi
2009-12-07 12:47 ` Miklos Szeredi
2009-12-07 13:03 ` Alan Cox
2009-12-07 13:08 ` Miklos Szeredi
2009-12-07 13:15 ` Alan Cox
2009-12-07 13:16 ` Miklos Szeredi
2009-12-07 14:13 ` Alan Cox
2009-12-07 14:25 ` Miklos Szeredi
2009-12-07 14:46 ` Alan Cox
2009-12-07 15:11 ` Miklos Szeredi
2009-12-07 17:40 ` Alan Cox
2009-12-07 15:03 ` Andrew Lutomirski
2009-12-07 15:03 ` Andrew Lutomirski
2009-12-07 15:50 ` Miklos Szeredi
2009-12-07 17:16 ` Alan Cox
2009-12-07 17:16 ` Alan Cox
2009-12-10 7:39 ` Pavel Machek
2009-12-06 8:46 ` Pavel Machek
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=4B1A7159.3070101@mit.edu \
--to=luto@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.