GNOME Bugzilla – Bug 735819
single native credential struct used for two purposes
Last modified: 2018-05-24 16:59:52 UTC
It seems that my credentials patch for NetBSD in Bug 728256 isn't quite right. It is correct as it provides a way of getting the pid of the attached process using struct unpcid with the LOCAL_PEEREID socket option, but I failed to realise that having defined struct unpcid as the native structure, that same structure would also be used for the SCM_CRED message to retrieve credentials. The problem is that in NetBSD, SCM_CRED sendmsg() takes a struct sockcred. struct sockcred is larger than struct unpcid, but does not contain a pid field. So, it isn't obvious to me how to fix this properly as I need to squeeze two different structs (for gestsockopt() and sendmsg()) into a single glib native struct. In the meantime, I suggest undefining G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED in the NetBSD case to correctly reflect reality.
Created attachment 285033 [details] [review] NetBSD credentials sticking plaster
(In reply to comment #0) > So, it isn't obvious to me how to fix this properly as I need to squeeze two > different structs (for gestsockopt() and sendmsg()) into a single glib native > struct. Although we don't currently do it with any other platforms, I don't think there's anything stopping us from having two different native types on NetBSD. This would require some reorganization of the macros in gcredentialsprivate.h; you'd need separate G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_TYPE and G_CREDENTIALS_SOCKET_GET_CREDENTIALS_TYPE defines rather than a single G_CREDENTIALS_NATIVE_TYPE, etc. (Though those defines could probably replace the existing G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED, etc, defines.)
Good idea! In the meantime, any chance of getting the sticking plaster in before the imminent release to prevent breakage?
Presumably g_credentials_get_native() is used in both cases? and then would need to be deprecated?
(In reply to comment #4) > Presumably g_credentials_get_native() is used in both cases? and then would > need to be deprecated? No, g_credentials_get_native() takes a GCredentialsType as an argument, so it could be used to fetch either type from the same credentials object.
Created attachment 285906 [details] [review] wip: attempt at 2 native credentials structs Before I get down to testing etc., is this what you had in mind?
Comment on attachment 285906 [details] [review] wip: attempt at 2 native credentials structs I wasn't expecting that you'd make any changes to the non-NetBSD code. Each other type would keep a single "native", and only NetBSD would have two fields in the struct GCredentials. > g_credentials_init (GCredentials *credentials) > { >+/* XXXPW also iniitialize unix_credentials_message? */ Yes, both need to be initialized, and both need to be updated (to the extent possible) by g_credentials_set_native().
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/923.