Bug 231234 - net/nss-pam-ldapd: pid formatted incorrectly in debug message (wrong printf format?)
Summary: net/nss-pam-ldapd: pid formatted incorrectly in debug message (wrong printf f...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Ryan Steinmetz
Depends on:
Reported: 2018-09-07 17:11 UTC by Norman Gray
Modified: 2018-09-09 16:17 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (zi)


Note You need to log in before you can comment on or make changes to this bug.
Description Norman Gray 2018-09-07 17:11:00 UTC
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.
Comment 1 Ryan Steinmetz freebsd_committer freebsd_triage 2018-09-07 17:15:47 UTC
This is probably a better question for the authors of the software or their mailing list:

Comment 2 Norman Gray 2018-09-07 19:20:52 UTC
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.
Comment 3 Norman Gray 2018-09-09 15:58:01 UTC
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
Comment 4 Ryan Steinmetz freebsd_committer freebsd_triage 2018-09-09 16:17:26 UTC

Perhaps this:

     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

     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 */