Skip to content

Pure Go FreeBSD UnixCredentials implementation#318

Closed
buglloc wants to merge 1 commit intogodbus:masterfrom
buglloc:cgo-free-freebsd
Closed

Pure Go FreeBSD UnixCredentials implementation#318
buglloc wants to merge 1 commit intogodbus:masterfrom
buglloc:cgo-free-freebsd

Conversation

@buglloc
Copy link

@buglloc buglloc commented Mar 6, 2022

First of all, thank you to your project, it helped me a lot :)
I'm currently porting my app to the FreeBSD and CGO requirement greatly complicates this, so I would be happy to drop it.

A few thoughts on the current implementation:

  • it seems the wrong ucred struct used for socket credentials management
  • man unix(4) says that we must only allocate buffer for the cmsgcred struct. Rest of work is going inside kernel and we can't pass anything else:
 Credentials of the sending process can be transmitted explicitly using a
 control message of type SCM_CREDS with a data portion of type struct
 cmsgcred, defined in <sys/socket.h> as follows:

 struct cmsgcred {
   pid_t cmcred_pid;       /* PID of sending process */
   uid_t cmcred_uid;       /* real UID of sending process */
   uid_t cmcred_euid;      /* effective UID of sending process */
   gid_t cmcred_gid;       /* real GID of sending process */
   short cmcred_ngroups;       /* number of groups */
   gid_t cmcred_groups[CMGROUP_MAX];     /* groups */
 };

 The sender should pass a zeroed buffer which will be filled in by the
 system.

 The group list is truncated to at most CMGROUP_MAX GIDs.

Therefore, it seems that nothing prevents us from determining the target buffer size, allocate it and send?

@guelfey
Copy link
Member

guelfey commented Mar 16, 2022

Generally makes sense. But IMO we should have these definitions upstream in x/sys, I filed golang/go#51711 for that. There's some more existing tooling there to capture this stuff also for different architectures, where there could be differences in struct sizes / alignment.

@guelfey
Copy link
Member

guelfey commented Dec 28, 2022

Done in #332.

@guelfey guelfey closed this Dec 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants