A bug with getsockopt(SOL_LOCAL, LOCAL_PEERCRED) ?

[Mark Millard]

On 2021-Apr-21, at 21:54, Gleb Popov <arrowd at freebsd.org> wrote:
> 
> 
> 
>> On Thu, Apr 22, 2021 at 1:00 AM Mark Millard <marklmi at yahoo.com> wrote:
>> 
>> On 2021-Apr-21, at 11:27, Gleb Popov <arrowd at freebsd.org> wrote:
>> > 
>> > This makes sense, thanks.
>> > 
>> > However, this code works on Linux and seems to return credentials of the user that started the process. I actually stumbled upon this when porting this code: https://github.com/CollaboraOnline/online/blob/master/net/Socket.cpp#L805
>> > 
>> > Would it make sense if FreeBSD followed Linux semantics in this case? If not, what are my options for porting the software?
>> 
>> From what I can tell . . .
>> 
>> FreeBSD defines LOCAL_PEERCRED and what goes with its use, not linux.
>> Linux defines SO_PEERCRED and what goes with its use, not FreeBSD.
>> 
>> If I understand right, your code is incompatible with the referenced
>> CollaboraOnline  code from just after the #else (so __FreeBSD__ case,
>> not the linux case):
>> 
>> getsockopt(getFD(), 0, LOCAL_PEERCRED, &creds, &credSize)
>> vs. your:
>> getsockopt(s, SOL_LOCAL, LOCAL_PEERCRED, &creds, &credSize)
>> 
>> Note the 0 vs. the SOL_LOCAL. Your code is a mix of Linux
>> and FreeBSD code when it should not be.
> 
> SOL_LOCAL is defined to 0, so this is fine.
> 
>> 
>> See also the following that involved replacing a SOL_LOCAL
>> with a 0 for getsockopt used with LOCAL_PEERCRED:
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234722
>> 
> 
> Yes, I'm aware that Linux SO_PEERCRED operates on socket level, while ours operates on level 0. This is taken in account
> in the code I posted.
> 
> As I said, the error stems from the fact that Linux allows getting creds from the listening socket.

(Is there any Linux documentation indicating that Linux
is required to allow that? POSIX? Etc,? Or is such code
depending on such properties operating outside the range
of the guarantees?)

Is the context linux compat code? Direct FreeBSD code?

It would be FreeBSD's compat handling that needs to match
Linux handling if FreeBSD is to span compatibility in the
subject area.

Does the compat code work as Linux (implicitly?) specifies?
(If not it might be more likely that FreeBSD would change
things sufficiently for it to work in at least that kind
of context.)

But if the compat code already matches the Linux behavior
for which socket(s) allow the accessbut direct FreeBSD does not . . .

FreeBSD appears to have its own programming model for direct
use, not exposing the temporary copy of the peercred that
is associated with the listening socket. If the compat code
works for Linux, it is not so obvious that FreeBSD would
change anything since it appears to have a working, usable
API: direct FreeBSD code needs to use FreeBSD's API. I'm
not sure how much FreeBSD tries to make direct FreeBSD code
allow code designed for Linux to work, except to help with
the Linux compat code doing the right thing in a simpler
way than otherwise.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)