From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott James Remnant Date: Tue, 25 Aug 2009 12:43:13 +0000 Subject: Re: [security] Race condition in udev Message-Id: <1251204193.4175.67.camel@quest> MIME-Version: 1 Content-Type: multipart/mixed; boundary="=-tKqNVyLU0BYzVnMx5Aaj" List-Id: References: <20090821102407.GA29609@florz.florz.dyndns.org> In-Reply-To: <20090821102407.GA29609@florz.florz.dyndns.org> To: linux-hotplug@vger.kernel.org --=-tKqNVyLU0BYzVnMx5Aaj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-08-25 at 14:21 +0200, Florian Zumbiehl wrote: > > > > reading some of the source of udev, I noticed what I would suspect = to be a > > > [...] > > >=20 > > > could someone possibly explain to me why there is that special codepa= th > > > for cases where the device node does already exist, so I can write a > > > patch that's not gonna break other functionality? > > >=20 > > For example, when using devtmpfs; in which case the device nodes alread= y > > exist. > >=20 > > Or when updating devices like /dev/null which are created before udevd > > is started by the init script when not using devtmpfs. >=20 > 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!? >=20 The rename() will fail. But you still need to apply any necessary ownership and mode changes. > > Or when racing with devmapper which creates /dev/mapper/foo devices at > > basically the same time as udev. >=20 > Seriously? How is a piece of code that does the existence check and > the subsequent action depending on the result of that check non-atomicall= y > supposed to help avoid some race condition resulting from possible > concurrent creation of a device node?! >=20 Read the code and find out. It works. Scott --=20 Scott James Remnant scott@canonical.com --=-tKqNVyLU0BYzVnMx5Aaj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkqT3GEACgkQSnQiFMl4yK6DQgCfcSebxfqNfOnzkATlYdizhiWh u4MAn2Fed3QtIy6BRX19Xvj7PsH4DuiM =Bd1r -----END PGP SIGNATURE----- --=-tKqNVyLU0BYzVnMx5Aaj--