On Thu, 24 Dec 1998 00:50:48 -0800 Jason Thorpe <thorpejat_private> wrote: > On Wed, 23 Dec 1998 09:28:35 +1100 > Darren Reed <avalonat_private> wrote: > > > In a way, that is exactly the type of thing he is referring to, BUT, > > LOCAL_CREDS must be supplied to be received as opposed to just "looked up" > > with getpeeruid() (my understanding anyway). > > Yes, they are a control message. This works well for SOCK_DGRAM, but > not as well for SOCK_STREAM, since w/ SOCK_STREAM you can connect and > then never send any data, thus the task wanting the credentials never > gets them. Actually, let me clarify this just a little. I was pretty tired when I wrote that reply :-) The credentials are supplied by the kernel. The kernel prevents the sender from supplying them, for obvious reasons. Upon reception of any datagram on a LOCAL_CREDS-enabled socket, the credentials are available in a control message. There is one credentials message per datagram if the option is enabled. For stream sockets, the credentials are supplied only once, when the sender first sends data. If the sender never sends data, the receiver never recieves the credentials. In any case, if you (the receiver) enable LOCAL_CREDS on the socket, the only work you have to do is the receive of the control message and parsing of it. The sending application does no additional work. It is out of the loop as far as the sending of credentials is concerned. I don't really see any value in getpeeruid() since it can _only_ apply to Unix domain sockets. Why invent a system call with no other use when you can just use existing general-purpose interfaces? Jason R. Thorpe thorpejat_private NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-5 Work: +1 650 604 0935 Moffett Field, CA 94035 Pager: +1 650 940 5942
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:26:21 PDT