Hi, > >>>> The device node is owned by root, what's the problem here? > >>> at least after the (first) chown() it potentially isn't owned by root, so > >>> your statement in that form is false. > >> The mknod() already happens with the configured mode, so after the > >> chown() we already have the configured permissions/ownership set. > > > > well, (a) there is this does-already-exist-so-let's-preserve-it > > part, in which case no mknod() does happen and (b) yeah, that was > > pretty much my point: The mknod() already happens with the configured > > mode(!), but AFAICS _not_ with the configured owner/group(!?). > > No, it happens with owner/group root, since that's who udev runs as Yeah. That applies to the mknod()-case only, though. > (unless I'm missing something). Do you not trust that owner/group for > some reason? :-) Why does it matter for this problem whether I trust root:root? Well, OK, if I _didn't_ trust them, maybe there would be some conflicts with the usual way linux systems are set up, but assuming that I _do_ trust them, how does trusting them help me when I tell udev to disallow group x (where x != root) from, say, writing to some device, but udev then goes and disallows group root from writing instead? > If you still don't trust root/root, how would you suggest fixing it, > given that there is no system call to set owner, group, and mode all at Actually, there is, it's called mknod(). > once? If the chown() / chmod() calls are reversed, then you have the > same problem in the other direction... Well, not really knowing the design of udev, I would guess that using mknod() to atomically create the node in exactly the intended state would be the cleanest way of doing it. Another secure alternative would be to at least never give _more_ permissions to anyone than what is specified in the configuration by taking away all the permissions from everyone around the owner/group change. The drawback to that variant is, of course, that there is some time window where permissions potentially are more restricted that what's specified in the configuration. 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
