EINVAL on PF_LOCAL recvmsg SCM_CREDENTIALS

[therealkenc]

This is kind of similar to #568 if you are doing work in that area, but I hadn't seen SO_PASSCRED and SCM_CREDENTIALS in the wild before, and I don't think it's been reported. There's a test case in TLPI over here.

wget http://www.man7.org/tlpi/code/download/tlpi-160726-dist.tar.gz
tar xf tlpi-160726-dist.tar.gz
cd tlpi-dist
make
cd sockets
./scm_cred_recv

In another terminal:

cd tlpi-dist/sockets
./scm_cred_send

The offending part of strace is:

socket(PF_LOCAL, SOCK_STREAM, 0)        = 3
bind(3, {sa_family=AF_LOCAL, sun_path="scm_cred"}, 110) = 0
listen(3, 5)                            = 0
accept(3, 0, NULL)                      = 4
setsockopt(4, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
recvmsg(4, 0x7fffc9ff3a80, 0)           = -1 EINVAL (Invalid argument)

[sunilmut]

Thanks for reporting the issue and the trace. The actual call that is failing is the sendmsg with ancillary message containing SCM_CREDENTIALS and the corresponding recvmsg is also failing. SCM_CREDENTIALS is currently not supported by WSL. I have opened a bug to track this. But, out of curiosity, did you run into this while trying out a scenario and the tlpi test is just a specific repro of it? Just wanted to make sure we cover the scenario as well when the bug is fixed.

[therealkenc]

Thanks. Newer versions of d-bus use the pattern I think. You'll probably hit this if/when WSL moves to Xenial as the base. Mostly I put it out there because if the pattern is in TLPI then it has probably been mimicked IRL.

[therealkenc]

Here's the dbus usage for what it's worth. In general, run the dbus test suite I posted here and you'll hit any unimplemented surface.

  union {
      struct cmsghdr hdr;
      char cred[CMSG_SPACE (sizeof (struct cmsgcred))];
  } cmsg;
  struct iovec iov;
  struct msghdr msg;
  iov.iov_base = buf;
  iov.iov_len = 1;

  _DBUS_ZERO(msg);
  msg.msg_iov = &iov;
  msg.msg_iovlen = 1;

  msg.msg_control = (caddr_t) &cmsg;
  msg.msg_controllen = CMSG_SPACE (sizeof (struct cmsgcred));
  _DBUS_ZERO(cmsg);
  cmsg.hdr.cmsg_len = CMSG_LEN (sizeof (struct cmsgcred));
  cmsg.hdr.cmsg_level = SOL_SOCKET;

[therealkenc]

Did a quick search on this out of curiosity after dinner. Pretty much anything that cares who it is talking to on the other side of the AF_UNIX socket hits this. For example syslog-ng over here. GIO which I mentioned in #754 over here. Postgresql #62 will hit this eventually here. This has all been obscured by us using AF_INET since the spring because local credentials don't make sense in a remote context, and anything remote does some kind of encryped password, key, or cookie exchange.

[therealkenc]

Build 14926 is oddly still getting an EINVAL on the same recvmsg() as the original post. dbus isn't complaining about SCM_CREDENTIALS anymore though; or at least, gnome-terminal launches with an unmodified dbus-1/session.conf.

write(1, "Receiving via stream socket\n", 28Receiving via stream socket) = 28
socket(PF_LOCAL, SOCK_STREAM, 0)        = 3
bind(3, {sa_family=AF_LOCAL, sun_path="scm_cred"}, 110) = 0
listen(3, 5)                            = 0
accept(3, 0, NULL)                      = 4
setsockopt(4, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
recvmsg(4, 0x7fffe8912d10, 0)           = -1 EINVAL (Invalid argument)
write(2, "ERROR [EINVAL Invalid argument] "..., 40) = 40
exit_group(1)                           = ?

[therealkenc]

The TLPI construct originally posted July 31 silently started working somewhere between 14926 and 14959. Feel free to mark as fixed if you like.