Re: Patch for Unix socket peer credentials

On Jul 19, 2006, at 10:40 AM, James F. Hranicky wrote:

> On Tuesday 18 July 2006 15:52, Eric Hodel wrote:
>
>>> +    if (uid < 0 || gid < 0)
>>> +        rb_raise(rb_eSocket, "Invalid credentials: uid %d, gid %
>>> d", uid, gid);
>>
>> Negative UID and GID are valid on some operating systems.
>
> Are negative values allowed on Linux? AFAICT, if the credentials  
> aren't
> available on Linux, say when I check a TCPServer socket's credentials
> after accepting a connection from another host, the system call  
> returns
> 0 but sets the uid & gid to -1:
>
>    ruby -rsocket -e 'p TCPServer.new(ARGV.shift).accept.peer_cred'  
> 5670
>    {:ruid=>nil, :rgid=>nil, :uid=>-1, :gid=>-1, :euid=>-1, :egid=>-1}
>
> If negative values are allowed, I really don't know what to do,  
> otherwise,
> I can raise an exception. I can also just leave it to the user to  
> raise an
> execption if e.g. Etc.getpwuid(creds[:uid]) fails.
>
> Attached is the latest patch.
>
> Questions/comments welcome.

On FreeBSD uid_t and gid_t are unsigned integers.  Searching google  
for 'negative uid' reveals that other operating systems also allow  
negative uids.

I don't have a Linux system, but I found a socket(7) man page that says:

> SO_PEERCRED
>
> Return the credentials of the foreign process connected to this  
> socket. This is only possible for connected PF_UNIX stream sockets  
> and PF_UNIX stream and datagram socket pairs created using  
> socketpair(2); see unix(7). The returned credentials are those that  
> were in effect at the time of the call to connect(2) or socketpair 
> (2). Argument is a ucred structure. Only valid as a getsockopt().

The man page doesn't say what happens if you use SO_PEERCRED on a non- 
PF_UNIX socket, so I think you need to check first and raise an  
exception if it is the wrong socket type.

-- 
Eric Hodel - [e-mail] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com