unix(4): Add SOL_LOCAL:LOCAL_PASSCRED

[cem]

Summary

This option is intended to be semantically identical to Linux's
SOL_SOCKET:SO_PASSCRED, to be used by linuxemul.

[trasz]

share/man/man4/unix.4

294

Hah! I guess this explains why I've been unable to make it work. (I had something similar to https://reviews.freebsd.org/D27012 in my tree for a while, but with LOCAL_CREDS instead; while it made Firefox work, it didn't work in couple of other cases. I've fixed quite a few unrelated things while procrastinating over this.)

[markj]

I find the naming of both the internal flags and the socket options kind of confusing. Rather than having two flags to do almost the same thing, you could have UNP_WANTCRED and a second flag, maybe UNP_WANTCRED_ALWAYS, that determines whether WANTCRED gets cleared after the initial read. The new socket option would set both flags.

I can't think of a better name than LOCAL_PASSCRED. Other than the naming this looks fine to me.

share/man/man4/unix.4

293

You might qualify that the difference applies only to SOCK_STREAM and SOCK_SEQPACKET sockets. The behaviour is identical for SOCK_DGRAM sockets. Something like, "... on every read from a .Dv SOCK_STREAM or .Dv SOCK_SEQPACKET socket, instead of just the first."

[cem]

In D27011#602724, @markj wrote:

I find the naming of both the internal flags and the socket options kind of confusing.

I completely agree.

Rather than having two flags to do almost the same thing, you could have UNP_WANTCRED and a second flag, maybe UNP_WANTCRED_ALWAYS, that determines whether WANTCRED gets cleared after the initial read. The new socket option would set both flags.

Sure, that works. We could also rename the former to WANTCRED_ONESHOT or something. I’ll admit my naming choice here was mostly guided by what would fit in the existing comment alignment scheme.

I can't think of a better name than LOCAL_PASSCRED. Other than the naming this looks fine to me.

Yeah, unless we want to throw _LINUX_ in there somewhere I don’t see anything better.

share/man/man4/unix.4

293

Will do. The other concern, I think, is what the interaction between these flags is. If PASSCRED is set, should setting CREDS turn it into oneshot mode? Should it produce an error?

[cem]

• Improve unpcb names somewhat
• Clarify that the difference from LOCAL_CREDS applies only to stream/seqpacket sockets

[markj]

In D27011#602795, @cem wrote:

In D27011#602724, @markj wrote:

I find the naming of both the internal flags and the socket options kind of confusing.

I completely agree.

Rather than having two flags to do almost the same thing, you could have UNP_WANTCRED and a second flag, maybe UNP_WANTCRED_ALWAYS, that determines whether WANTCRED gets cleared after the initial read. The new socket option would set both flags.

Sure, that works. We could also rename the former to WANTCRED_ONESHOT or something. I’ll admit my naming choice here was mostly guided by what would fit in the existing comment alignment scheme.

I like WANTCRED_ONESHOT better for the original flag.

I can't think of a better name than LOCAL_PASSCRED. Other than the naming this looks fine to me.

Yeah, unless we want to throw _LINUX_ in there somewhere I don’t see anything better.

Maybe LOCAL_CREDS_PERSISTENT? Kind of an awkward name, but it's really just for Linux compatibility anyway.

share/man/man4/unix.4

293

I'd be conservative and make it an error to set both. If there's ever a need to allow it we can relax that rule.

[cem]

• Rename WANTCRED => WANTCRED_ONESHOT
• Rename LOCAL_PASSCRED to LOCAL_CREDS_PERSISTENT
• Make LOCAL_CREDS{,_PERSISTENT} mutually exlusive (EINVAL from setsockopt) and document in manual page.

[markj]

LGTM with the lock leak fixed.

sys/kern/uipc_usrreq.c

1449

The pcb lock is leaked here.

[cem]

sys/kern/uipc_usrreq.c

1449

Ah, my bad. Thanks for spotting that.

[cem]

• Fix PCB lock leak
• Fix 'error' assignment operator