On Fri, Aug 21, 2009 at 2:12 PM, Seth Willits<[email protected]> wrote: >> The second bit of information is that permissions are tested at the time >> of the open(). Once you have the file descriptor, you can use it without >> further checks. > > That's the bit that confuses me, because it seems to be a security gap. It > sounds like I could just spawn an application which reads from every single > file descriptor from 1 on up. If any other process opened a protected file > then my app could read its data without any security check at all? That > doesn't seem right.
Think of it this way: every process has stdin, stdout, and stderr opened for it on file descriptors 0, 1, and 2 respectively. But not all processes share the same stdin, right! If I do this command: echo "hello" | gzip -c > somefile.txt The stdout of "echo" is connected to the stdin of "gzip", and "gzip"s stdout is connected (by the shell) to a file. So even though they all have stdin as 0, and stdout as 1, each command sees something different... because file descriptor numbers are local to the process. When you use sendmsg to pass a fd, you are telling the kernel "dup() file fd into the receiving process during transit" (because you can't do that yourself). Maybe on the sendmsg side of things, the fd is 34. But on the recvmsg side, it could end up as 42! Who knows, and you shouldn't care. Unsurprisingly, Windows takes a slightly different approach. Instead of having the kernel dup() the handle in transit, you do it youself using DuplicateHandle(). The resultant handle is meaningly in your process, you're just supposed to copy the raw value to the destination however you like. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
