You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For non-Linux sockets, libqb appears to use the effective UID/GID as the socket credentials, and given the member naming in struct qb_ipcc_connection (i.e. euid/egid), it seems that was the original intent as well.
However, for Linux sockets, libqb enables SO_PASSCRED when connecting, and qb_ipc_auth_creds() pulls the other side's credentials from SCM_CREDENTIALS. I believe libqb on the other side lets the credentials default, which the kernel will set to the user's real UID/GID. I think only root can set SCM_CREDENTIALS when connecting, so it might not be helpful in all cases, but it would nice to use the effective UID/GID when possible.
@kgaillot I actually meant that the setuid wrapper written by the original poster could. I don't think the Pacemaker tools have any business manipulating these IDs.
For non-Linux sockets, libqb appears to use the effective UID/GID as the socket credentials, and given the member naming in struct qb_ipcc_connection (i.e. euid/egid), it seems that was the original intent as well.
However, for Linux sockets, libqb enables SO_PASSCRED when connecting, and qb_ipc_auth_creds() pulls the other side's credentials from SCM_CREDENTIALS. I believe libqb on the other side lets the credentials default, which the kernel will set to the user's real UID/GID. I think only root can set SCM_CREDENTIALS when connecting, so it might not be helpful in all cases, but it would nice to use the effective UID/GID when possible.
For context, see this mailing list thread:
https://www.mail-archive.com/[email protected]/msg10681.html
The text was updated successfully, but these errors were encountered: