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. > 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. 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. > 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" Scott -- Scott James Remnant scott@xxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
