GNOME Bugzilla – Bug 629267
g_unix_connection_send_credentials() should allow us to define the byte sent
Last modified: 2010-09-13 15:39:42 UTC
g_unix_connection_send_credentials() is great and all but useless for my use case as I need to choose the byte sent with the credentials. I know it's a bit late, but could we imagine breaking the API and adding a "byte" argument to this function? If it's ok, I'd be happy to cook a patch.
And of course, g_unix_connection_receive_credentials() should allow us to get the byte which has been read.
The main idea behind g_unix_connection_{send,receive}_credentials() is that this is the API we want to work everywhere that GUnixConnection itself works (e.g. any Unix). Even when credential passing isn't available, we should be able to emulate it with g_socket_get_credentials() (e.g. SO_PEERCRED on Linux) or similar. That's the idea though (we added this because GDBus needs it and we want GDBus to work everywhere). So the concern here is that some (old? obscure?) Unix may need to pass a NUL byte e.g. we cannot control what byte is passed. I'm not 100% sure about this - it would be good to do some archeological research here... Maybe we can add a g_unix_connection_{send,receive}_credentials_with_byte() set of functions and make fewer guarantees about that. Then g_unix_connection_{send,receive}_credentials() are trivial one-line functions calling the _with_byte() variants. Then again, if there's only one application (Telepathy) needing this and we're not sure whether it's portable, maybe it's just easier to keep it in Telepathy. Then again, it's more likely that GLib will get the portability fixes for non-Linux platforms (I just committed FreeBSD support yesterday so GDBus works there too) so maybe after all that's a fine idea. I don't know.
afaik there is no requirement to send a nul byte. that's just a convention. in fact, you don't even need to send one byte. in reality, the only requirement for portability is that a non-zero number of bytes are sent.
(In reply to comment #2) > So the concern here is that some (old? obscure?) Unix may need to pass a NUL > byte e.g. we cannot control what byte is passed. No. The weirdness is because we want an API that does "send just credentials" (or "send just a file descriptor"), but there is no such API. The best we can do is to get sendmsg() to send the credentials/fds for us as a side effect of making it send application-level data. But sendmsg() doesn't care what that application-level data is just because you're using SCM_CREDENTIALS/SCM_RIGHTS, any more than it cares what the application-level data is in any other case.
So, should I go with the g_unix_connection_{send,receive}_credentials_with_byte() variant?
Actually, what I really need is an async version of this API (bug #629503).
You can very easily do this for yourself by creating a GUnixCredentialsMessage and sending it using g_socket_send_message(). The API on GUnixConnection (much like the fd-passing one) is just convenience API for the common case of sending a nul byte. I don't think we want to expand these APIs any further.