Hi,
> On Sat, Aug 29, 2009 at 16:41, Florian Zumbiehl<florz@xxxxxxxx> wrote:
> >> On Sat, Aug 29, 2009 at 16:20, Florian Zumbiehl<florz@xxxxxxxx> wrote:
> >> >> > diff --git a/libudev/libudev-util-private.c b/libudev/libudev-util-private.c
> >> >> > index 3641b36..28008c5 100644
> >> >> > --- a/libudev/libudev-util-private.c
> >> >> > +++ b/libudev/libudev-util-private.c
> >> >> > @@ -102,6 +102,10 @@ int util_unlink_secure(struct udev *udev, const char *filename)
> >> >> > {
> >> >> > int retval;
> >> >> >
> >> >> > + retval = chmod(filename, 0000);
> >> >> > + if (retval)
> >> >> > + err(udev, "chmod(%s, 0000) failed: %m\n", filename);
> >> >> > +
> >> >> > retval = chown(filename, 0, 0);
> >> >> > if (retval)
> >> >> > err(udev, "chown(%s, 0, 0) failed: %m\n", filename);
> >> >>
> >> >> We need only one chmod() here. I changed the order.
> >> >
> >> > no, you need both. In the case that the device belonged to non-root before,
> >> > the owner could do a chmod() in between the chmod() and chown() and thus
> >> > retain privileges on the device node.
> >>
> >> What about fchmod(), how's that handled in such case?
> >
> > I assumed that it's guaranteed for there to not be any open fds on the
> > device anymore at unlink() time!?
>
> The entire hardlink thing is purely theoretical and a pretty useless
> exercise because we are on our own filesystem and can not hardlink
That's not just the "usual configuration"?
> anywhere else. But I guess, there can not be any assumptions about no
> fds open.
It just occured to me that it doesn't matter for this anyhow - fchmod()
applies the same checks as chmod(), so anyone (non-privileged and non-root)
who has an open fd can't fchmod() after the chown() to root anymore.
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
