When running nslcd in debug mode (`nslcd -d`), I see lines such as DEBUG: connection from pid=18446744073709551615 uid=0 gid=0 This is an implausible pid number. This originates from a line log_log(LOG_DEBUG, "connection from pid=%lu uid=%lu gid=%lu", (unsigned long int)pid, (unsigned long int)uid, (unsigned long int)gid); in nslcd.c (I'm looking at the download of 0.9.10 from https://arthurdejong.org/nss-pam-ldapd/downloads, but I don't imagine the FreeBSD patched version is too different). This does look OK to me at first sight -- pid is pid_t, which is __pid_t, which /usr/include/sys/_types.h says is __int32t -- and the explicit cast to (unsigned long int) _should_ be OK and match the %lu; but I always get such promotions wrong first time, and the output above does look suspiciously as if an integer conversion has been bungled somewhere, either in the original or in the port. This isn't purely cosmetic, since I'm using this debug mode to try to locate which PID is making a connection to nslcd.
This is probably a better question for the authors of the software or their mailing list: https://lists.arthurdejong.org/nss-pam-ldapd-users/
Done: see https://lists.arthurdejong.org/nss-pam-ldapd-users/2018/msg00056.html Note that, on further investigation, I realise this isn't a printf issue, but an unhandled error getting a PID in a nearby bit of code. I reported it here first in case it was a porting issue, but you're right, it probably makes sense to report it upstream.
Update, after a note on the source email support list. The upstream author noted [1] that: > I don't think that FreeBSD's LOCAL_PEERCRED facility exposes the > process ID of the socket peer. I sadly can't test this at the moment > because by FreeBSD virtual machine is not working. I'm not aware of any > other mechanism to find the PID of the nslcd client. If the FreeBSD port maintainer knows of a way of getting this information, that might be something worth adding to the port here or, probably better, noting to the upstream author. [1] https://lists.arthurdejong.org/nss-pam-ldapd-users/2018/msg00058.html
https://www.freebsd.org/cgi/man.cgi?query=unix&sektion=4 Perhaps this: CONTROL MESSAGES The UNIX-domain sockets support the communication of UNIX file descrip- tors and process credentials through the use of the msg_control field in the msg argument to sendmsg(2) and recvmsg(2). The items to be passed are described using a struct cmsghdr that is defined in the include file <sys/socket.h>. To send file descriptors, the type of the message is SCM_RIGHTS, and the data portion of the messages is an array of integers representing the file descriptors to be passed. The number of descriptors being passed is defined by the length field of the message; the length field is the sum of the size of the header plus the size of the array of file descriptors. The received descriptor is a duplicate of the sender's descriptor, as if it were created via dup(fd) or fcntl(fd, F_DUPFD_CLOEXEC, 0) depending on whether MSG_CMSG_CLOEXEC is passed in the recvmsg(2) call. Descriptors that are awaiting delivery, or that are purposely not received, are auto- matically closed by the system when the destination socket is closed. 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 */ };