From: Scott James Remnant <scott@canonical.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [security] Race condition in udev
Date: Tue, 25 Aug 2009 16:08:13 +0000 [thread overview]
Message-ID: <1251216493.4175.71.camel@quest> (raw)
In-Reply-To: <20090821102407.GA29609@florz.florz.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]
On Tue, 2009-08-25 at 16:22 +0200, Florian Zumbiehl wrote:
> > > > > well, in those two cases always rename()ing the new node into place would
> > > > > work, too!? That would be a different strategy than what's in
> > > > > place at the moment, but it wouldn't need a special case!?
> > > > >
> > > > The rename() will fail.
> > >
> > > Because?
> > >
> > POSIX.
>
> More specifically?
>
> And anyhow, I thought we were talking about the Linux kernel?!
>
If you don't know why rename() might fail, you really shouldn't be
mucking around with this kind of code.
> > > > > > Or when racing with devmapper which creates /dev/mapper/foo devices at
> > > > > > basically the same time as udev.
> > > > >
> > > > > Seriously? How is a piece of code that does the existence check and
> > > > > the subsequent action depending on the result of that check non-atomically
> > > > > supposed to help avoid some race condition resulting from possible
> > > > > concurrent creation of a device node?!
> > > > >
> > > > Read the code and find out. It works.
> > >
> > > Guess how I found out that it can not work.
> > >
> > I don't know, you haven't given any detail of any problems you've
> > encountered.
>
> I haven't "encountered any problems", nor have I claimed to have
> "encountered any problems".
>
> You stated that the codepath in udev-node.c for the case when a
> device node does already exist was somehow there for the case
> when udev races with devmapper. I noted that that codepath is not
> of any use in such a case, and that your argument thus is invalid.
>
Since I wrote this code, and the code in devmapper, and have not only
strenuously tested it; but have at least 18 million for whom it works
every day, I'd argue that my argument is quite valid ;-)
Scott
--
Scott James Remnant
scott@canonical.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-08-25 16:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-21 10:24 [security] Race condition in udev Florian Zumbiehl
2009-08-21 11:14 ` Kay Sievers
2009-08-21 11:25 ` Florian Zumbiehl
2009-08-21 11:59 ` Kay Sievers
2009-08-22 0:19 ` Florian Zumbiehl
2009-08-22 2:25 ` Bryan Kadzban
2009-08-22 3:11 ` Florian Zumbiehl
2009-08-25 11:32 ` Florian Zumbiehl
2009-08-25 11:58 ` Scott James Remnant
2009-08-25 12:03 ` Kay Sievers
2009-08-25 12:21 ` Florian Zumbiehl
2009-08-25 12:43 ` Scott James Remnant
2009-08-25 12:55 ` Florian Zumbiehl
2009-08-25 13:11 ` Florian Zumbiehl
2009-08-25 13:31 ` Scott James Remnant
2009-08-25 14:22 ` Florian Zumbiehl
2009-08-25 16:08 ` Scott James Remnant [this message]
2009-08-25 16:27 ` Florian Zumbiehl
2009-08-25 16:49 ` Scott James Remnant
2009-08-25 17:31 ` Florian Zumbiehl
2009-08-25 17:42 ` Greg KH
2009-08-25 18:04 ` Robby Workman
2009-08-25 18:05 ` Scott James Remnant
2009-08-25 18:11 ` Florian Zumbiehl
2009-08-25 18:17 ` Kay Sievers
2009-08-25 18:20 ` Greg KH
2009-08-25 18:21 ` Greg KH
2009-08-25 18:38 ` Florian Zumbiehl
2009-08-25 18:53 ` Florian Zumbiehl
2009-08-25 19:10 ` Greg KH
2009-08-25 19:28 ` Mr POSIX
2009-08-25 21:55 ` Florian Zumbiehl
2009-08-26 11:22 ` Scott James Remnant
2009-08-26 17:41 ` Florian Zumbiehl
2009-08-26 21:00 ` Greg KH
2009-08-27 6:54 ` Matthias Schwarzott
2009-08-27 15:09 ` Florian Zumbiehl
2009-08-27 15:13 ` Florian Zumbiehl
2009-08-27 15:22 ` Greg KH
2009-08-27 15:52 ` Florian Zumbiehl
2009-08-27 16:03 ` Florian Zumbiehl
2009-08-28 17:34 ` Florian Zumbiehl
2009-08-29 14:15 ` Kay Sievers
2009-08-29 14:20 ` Florian Zumbiehl
2009-08-29 14:32 ` Kay Sievers
2009-08-29 14:41 ` Florian Zumbiehl
2009-08-29 14:47 ` Kay Sievers
2009-08-29 14:58 ` Florian Zumbiehl
2009-09-04 19:12 ` Florian Zumbiehl
2009-09-04 19:16 ` Florian Zumbiehl
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=1251216493.4175.71.camel@quest \
--to=scott@canonical.com \
--cc=linux-hotplug@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).