That shouldn't really be a suprise; I'm actually more suprised that
current BSD version do honor the permissions on Unix domain sockets;
they weren't relevant in BSD 4.3 (SunOS 4.x) either.
I've tried some tests and it seems that the mode of a unix domain socket
is ignored in both (created mode 0 in Solaris 2, mode 777 in SunOS 4).
If I protect the directory that holds the socket (remove execute permission;
read permission obviously isn't used), then I cannot connect both in SunOS 4.x
and in Solaris 2.x.
The placeholder for a Unix domain socket in Solaris is a mode 0 pipe.
(Though in 2.6 this changes and sockets are again first class citizens)
As stated in the original unix domain socket documentation "the filesystem
entry is an artifact of the implementation" or words to that effect.
Depending on the permissions or even the existance in the filesystem of
that node is a bug.
>recently, I've been trying to write some code that would give me the
>user id of the person at the other end of a unix socket or tli
>connection, but I haven't had much luck. The only way I think I could
>to this would be to poke around in the kernel structures for the tl
>device, which I really don't want to do. The undocumented door calls
>seem to provide authentication information, but that would be a worse.
>Oh, well. Anyone have any ideas?
Well, the TLI interface allows you to get at the uids/gids directly, but
it doesn't seem all that documented.
Check <sys/tl.h>. First you'll need to switch on credentials exchanging
w/ TL_IOC_CREDOPT and then you'll receive the credentials as options
with the data.
This is what the rpc code uses as secure authentication for loopback
calls (keyserv), but it seems it's a Sun private interface.
Casper