----- Original Message -----
> Nathan Scott <nathans@xxxxxxxxxx> writes:
>
> > [...]
> > secureconnect.c
> > - some Dave-style comments
> > - __pmSetSockOpt - there's no SO_PASSCRED on Win32/Win64 - sneak it into
> > the existing #ifdef there for SO_EXCLUSIVEADDRUSE perhaps?
> > [...]
>
> Is there a reason to use SO_PASSCRED vice SO_PEERCRED? The latter seems
> simpler.
>
No good reason - I've simply never come across it before! (its not
mentioned on the unix(7) man page). It sure does look a cleaner API.
BTW Dave, looks like these things will need "proper" configure tests
after all - there is no SO_PASSCRED on Mac OS X, but there does seem
to be a "LOCAL_PEERCRED"...
"The effective credentials (i.e., the user ID and group list) of a peer on
a SOCK_STREAM socket may be
obtained using the LOCAL_PEERCRED socket option. This may be used by a
server to obtain and verify the creden-
tials of its client, and vice versa by the client to verify the
credentials of the server. These will arrive in
the form of a filled in struct xucred (defined in sys/ucred.h)."
So, uses a differently named structure too (with different fields).
Fun! I guess a platform-independent struct type will be needed bit
like was done for the socklen_t type (__pmSockLen).
cheers.
--
Nathan
|