Hi, > On Tue, 2009-08-25 at 23:55 +0200, Florian Zumbiehl wrote: > > > isn't that a bit at odds with the fact that the kernel does _not_ check > > against the accumulation of all of owner, group and others permissions > > that would apply to the process in question? Wouldn't really be all that > > difficult to implement, after all. > > > The kernel doesn't check that the netmask of a network route is of the > form <1>s<0>s and not something random like 10101010... yet if you try > and use that kind of network route, you'll discover that it just won't > work out. now, how is that "analogy" supposed to support your statement that the traditional interpretation of permissions on unix systems was the opposite of what the documented behaviour is? > > Well, IMO you are mixing up what the userspace conventions of most > > desktop/server installations look like, and what the security model > > of the kernel is. > > > > Given that udev is nearly a component of the kernel, IMO it should > > follow the security model of the kernel, and not force userspace to > > follow any additional conventions. > > > udev doesn't enforce any permission or mode restriction; you can put > whatever you like in there. > > Of course, it probably won't work out. So, you are saying "your way won't work, but I don't force you to use my way", right? Anyhow, the current code does potentially allow more access than one would expect when interpreting udev's configuration using the well-known semantics of unix permissions, which is kindof worse than "just not working". > More to the point, you haven't explained how to work around the fact > that simply inverting the chmod/chown (or any variation of that) doesn't > remove the race condition - just moves it between the user or group. If I may quote from one of my mails: | b) (optionally mknod() with mode&0600), chmod() to mode&0600, | chown() to configured owner/group, chmod() to configured mode. | | This one potentially temporarily reduces permissions to a proper | subset of both the permissions before and after the change - | I guess that that's not desirable? Possibly skipping it all when no changes are necessary would even make it free from any possible regressions from the current state? > > You didn't really answer a question the answer to which probably would be > > rather important in this context: Is there any way for a non-privileged > > process to drop a group membership without exec()ing? > > > > Also, I really would like to understand why the rename() in that scenario > > could fail, independent of whether we'll use that for anything. > > > Apparently I'm "Mr GOOGLE" as well as "Mr POSIX" "GOOGLE"? What's that? Well, I certainly would appreciate anything I could feed into this google thing in order to get to an understanding of the issues. But a reference to a specific paragraph of text that you think applies in this case really would be appreciated even more. 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
