Re: [gamin] socket credentials patch for NetBSD

["Johnny C. Lam" <jlam NetBSD org>]

Daniel Veillard wrote:
>   Changing the protocol on NetBSD where it doesn't work currently is fine,
> but breaking the protocol API without added value (the pid, gid are trivially
> spoofable so this doesn't add any security on Linux at least, while making
> the code paths more complex) is not IMHO acceptable. I prefer to keep
> the Linux and FreeBSD code as-is, still send a nul byte around and keep
> the compatibility, it's inforamtion we can't trust anyway. The problem
> of changing the API is that if you upgrade, kill the server or restart any
> client then there is a protocol mismatch. Having a special protocol for
> OS lacking secure local socket infrastructure is a workaround, I'm okay 
> with this but not with generalizing the case. 

I would actually like to do this a bit better.

I've taken another look through the gamin sources, and it looks like the 
client doesn't actually care about the server's PID, and the server 
wants to know the client's PID because it uses it as a unique label to 
identify the client.  Moreover, the server only uses the PID when 
printing debugging messages.  Thus it seems that we could use something 
else it its place in the connection and listener structures, e.g. a 
unique int32_t integer in place of a pid_t.  Therefore, I shouldn't even 
need to push the PID through the socket on NetBSD -- I can just push 
NULs back and forth as before, but have the credential-checking routines 
generate a unique int32_t label in place of the PID for storage.  This 
would allow keeping the exact same protocol for all platforms.

Do you see anything wrong with my understanding/reasoning?

If not, I'd like to change the name of the "pid" and "pidname" fields in 
various structs to be "id" and "idname", and change the routines that 
{get,set}_{pid,pidname} to be {get,set}_{id,idname}.  This would reflect 
the fact that those aren't necessarily PIDs and pid-to-name strings, 
though I would keep it that way on Linux and FreeBSD where that 
information is easily discovered.

Would that be okay?

	Cheers,

	-- Johnny Lam <jlam NetBSD org>