UNIX(7)

UNIX(7)

[Alexey Tikhonov]

Hello.

There is a discrepancy between the man page description of
'SO_PEERCRED' and real behavior.

`man 7 unix` states:
```
       SO_PEERCRED
              This read-only socket option returns the credentials of
              the peer process connected to this socket.  The returned
              credentials are those that were in effect at the time of
              the call to connect(2) or socketpair(2).
```

This doesn't match real behavior in following situation (just an example):
 - process starts with uid=0, gid=0
 - process creates UNIX socket, binds it, listens on it
 - process changes to uid=uid1, git=gid1 (using `setresuid()`, `setresgid()`)
 - another process connects to the listening socket and requests
peer's credentials using `getsockopt(... SOL_SOCKET, SO_PEERCRED ...)`

According to the man page: SO_PEERCRED should report (uid1, gid1),
because peer process was running under (uid1, gid1) "at the time of
the call to connect(2)"
In reality SO_PEERCRED reports (0, 0)
Reproducing code is available in
https://bugzilla.redhat.com/show_bug.cgi?id=2247682

I'm not entirely sure if this is a real bug or rather a  poor
description in the man page, but I tend to think that it's the latter.

Re: UNIX(7)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

Hello Alexey,

On Fri, Dec 01, 2023 at 01:16:27PM +0100, Alexey Tikhonov wrote:
> Hello.
> 
> There is a discrepancy between the man page description of
> 'SO_PEERCRED' and real behavior.
> 
> `man 7 unix` states:
> ```
>        SO_PEERCRED
>               This read-only socket option returns the credentials of
>               the peer process connected to this socket.  The returned
>               credentials are those that were in effect at the time of
>               the call to connect(2) or socketpair(2).
> ```
> 
> This doesn't match real behavior in following situation (just an example):
>  - process starts with uid=0, gid=0
>  - process creates UNIX socket, binds it, listens on it
>  - process changes to uid=uid1, git=gid1 (using `setresuid()`, `setresgid()`)
>  - another process connects to the listening socket and requests
> peer's credentials using `getsockopt(... SOL_SOCKET, SO_PEERCRED ...)`
> 
> According to the man page: SO_PEERCRED should report (uid1, gid1),
> because peer process was running under (uid1, gid1) "at the time of
> the call to connect(2)"
> In reality SO_PEERCRED reports (0, 0)
> Reproducing code is available in
> https://bugzilla.redhat.com/show_bug.cgi?id=2247682
> 
> I'm not entirely sure if this is a real bug or rather a  poor
> description in the man page, but I tend to think that it's the latter.

I've CCed netdev@, since they probably know better.

Thanks,
Alex

--
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: UNIX(7)

[Kuniyuki Iwashima]

From: Alejandro Colomar <alx@kernel.org>
Date: Fri, 1 Dec 2023 13:54:39 +0100
> Hello Alexey,
> 
> On Fri, Dec 01, 2023 at 01:16:27PM +0100, Alexey Tikhonov wrote:
> > Hello.
> > 
> > There is a discrepancy between the man page description of
> > 'SO_PEERCRED' and real behavior.
> > 
> > `man 7 unix` states:
> > ```
> >        SO_PEERCRED
> >               This read-only socket option returns the credentials of
> >               the peer process connected to this socket.  The returned
> >               credentials are those that were in effect at the time of
> >               the call to connect(2) or socketpair(2).
> > ```
> > 
> > This doesn't match real behavior in following situation (just an example):
> >  - process starts with uid=0, gid=0
> >  - process creates UNIX socket, binds it, listens on it
> >  - process changes to uid=uid1, git=gid1 (using `setresuid()`, `setresgid()`)
> >  - another process connects to the listening socket and requests
> > peer's credentials using `getsockopt(... SOL_SOCKET, SO_PEERCRED ...)`
> > 
> > According to the man page: SO_PEERCRED should report (uid1, gid1),
> > because peer process was running under (uid1, gid1) "at the time of
> > the call to connect(2)"
> > In reality SO_PEERCRED reports (0, 0)
> > Reproducing code is available in
> > https://bugzilla.redhat.com/show_bug.cgi?id=2247682
> > 
> > I'm not entirely sure if this is a real bug or rather a  poor
> > description in the man page, but I tend to think that it's the latter.

When calling getsockopt(), we cannot know dynamically who the peer's
owner is.  So, we just initialise the cred when we know the owner,
and it's the caller of listen(), connect(), and socketpair().

In your case, the listener's cred is initialised with the caller's
cred during the first liten().

  listener's peer_cred = get_cred(rcu_dereference_protected(current->cred, 1))

And connect() will initialise two creds as follows:

  connect()er's peer_cred = listener's peer_cred
  new socket's peer_cred = get_cred(rcu_dereference_protected(current->cred, 1))

If you call listen() again after setresuid() and before connect(),
you can update the listener's cred and get the new IDs at the final
getsockopt().

Re: UNIX(7)

[Alexey Tikhonov]

On Fri, Dec 1, 2023 at 11:08 PM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Alejandro Colomar <alx@kernel.org>
> Date: Fri, 1 Dec 2023 13:54:39 +0100
> > Hello Alexey,
> >
> > On Fri, Dec 01, 2023 at 01:16:27PM +0100, Alexey Tikhonov wrote:
> > > Hello.
> > >
> > > There is a discrepancy between the man page description of
> > > 'SO_PEERCRED' and real behavior.
> > >
> > > `man 7 unix` states:
> > > ```
> > >        SO_PEERCRED
> > >               This read-only socket option returns the credentials of
> > >               the peer process connected to this socket.  The returned
> > >               credentials are those that were in effect at the time of
> > >               the call to connect(2) or socketpair(2).
> > > ```
> > >
> > > This doesn't match real behavior in following situation (just an example):
> > >  - process starts with uid=0, gid=0
> > >  - process creates UNIX socket, binds it, listens on it
> > >  - process changes to uid=uid1, git=gid1 (using `setresuid()`, `setresgid()`)
> > >  - another process connects to the listening socket and requests
> > > peer's credentials using `getsockopt(... SOL_SOCKET, SO_PEERCRED ...)`
> > >
> > > According to the man page: SO_PEERCRED should report (uid1, gid1),
> > > because peer process was running under (uid1, gid1) "at the time of
> > > the call to connect(2)"
> > > In reality SO_PEERCRED reports (0, 0)
> > > Reproducing code is available in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2247682
> > >
> > > I'm not entirely sure if this is a real bug or rather a  poor
> > > description in the man page, but I tend to think that it's the latter.
>
> When calling getsockopt(), we cannot know dynamically who the peer's
> owner is.  So, we just initialise the cred when we know the owner,
> and it's the caller of listen(), connect(), and socketpair().
>
> In your case, the listener's cred is initialised with the caller's
> cred during the first liten().
>
>   listener's peer_cred = get_cred(rcu_dereference_protected(current->cred, 1))

Thank you for the explanation.
So this is an omission in the man page.

>
> And connect() will initialise two creds as follows:
>
>   connect()er's peer_cred = listener's peer_cred
>   new socket's peer_cred = get_cred(rcu_dereference_protected(current->cred, 1))
>
> If you call listen() again after setresuid() and before connect(),
> you can update the listener's cred and get the new IDs at the final
> getsockopt().
>

[patch] unix.7: SO_PEERCRED: Mention listen(2)

[Alexey Tikhonov]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

From c835c1c7c7047590263cf6c6d516092b165e013d Mon Sep 17 00:00:00 2001
From: Alexey Tikhonov <atikhono@redhat.com>
Date: Wed, 20 Dec 2023 18:28:34 +0100
Subject: [PATCH] unix.7: SO_PEERCRED: Mention listen(2)

In case of connected AF_UNIX stream sockets, server-side
credentials are set at the time of a call to listen(2),
not when client-side calls connect(2).

This is important if server side process changes UID/GID
after listen(2) and before connect(2).

Reproducer is available in https://bugzilla.redhat.com/show_bug.cgi?id=2247682

Behavior was confirmed in the email thread
https://lore.kernel.org/linux-man/CABPeg3a9L0142gmdZZ+0hoD+Q3Vgv0BQ21g8Z+gf2kznWouErA@mail.gmail.com/

Signed-off-by: Alexey Tikhonov <atikhono@redhat.com>
---
 man7/unix.7 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/man7/unix.7 b/man7/unix.7
index e9edad467..71cdfc758 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -331,7 +331,8 @@ This read-only socket option returns the
 credentials of the peer process connected to this socket.
 The returned credentials are those that were in effect at the time
 of the call to
-.BR connect (2)
+.BR connect (2),
+.BR listen (2),
 or
 .BR socketpair (2).
 .IP
-- 
2.41.0

[-- Attachment #2: 0001-unix.7-SO_PEERCRED-Mention-listen-2.patch --]
[-- Type: text/x-patch, Size: 1220 bytes --]

From c835c1c7c7047590263cf6c6d516092b165e013d Mon Sep 17 00:00:00 2001
From: Alexey Tikhonov <atikhono@redhat.com>
Date: Wed, 20 Dec 2023 18:28:34 +0100
Subject: [PATCH] unix.7: SO_PEERCRED: Mention listen(2)

In case of connected AF_UNIX stream sockets, server-side
credentials are set at the time of a call to listen(2),
not when client-side calls connect(2).

This is important if server side process changes UID/GID
after listen(2) and before connect(2).

Reproducer is available in https://bugzilla.redhat.com/show_bug.cgi?id=2247682

Behavior was confirmed in the email thread
https://lore.kernel.org/linux-man/CABPeg3a9L0142gmdZZ+0hoD+Q3Vgv0BQ21g8Z+gf2kznWouErA@mail.gmail.com/

Signed-off-by: Alexey Tikhonov <atikhono@redhat.com>
---
 man7/unix.7 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/man7/unix.7 b/man7/unix.7
index e9edad467..71cdfc758 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -331,7 +331,8 @@ This read-only socket option returns the
 credentials of the peer process connected to this socket.
 The returned credentials are those that were in effect at the time
 of the call to
-.BR connect (2)
+.BR connect (2),
+.BR listen (2),
 or
 .BR socketpair (2).
 .IP
-- 
2.41.0

Re: [PATCH] unix.7: SO_PEERCRED: Mention listen(2)

[Kuniyuki Iwashima]

From: Alexey Tikhonov <atikhono@redhat.com>
Date: Wed, 20 Dec 2023 18:28:34 +0100
> In case of connected AF_UNIX stream sockets, server-side
> credentials are set at the time of a call to listen(2),
> not when client-side calls connect(2).
> 
> This is important if server side process changes UID/GID
> after listen(2) and before connect(2).
> 
> Reproducer is available in https://bugzilla.redhat.com/show_bug.cgi?id=2247682
> 
> Behavior was confirmed in the email thread
> https://lore.kernel.org/linux-man/CABPeg3a9L0142gmdZZ+0hoD+Q3Vgv0BQ21g8Z+gf2kznWouErA@mail.gmail.com/
> 
> Signed-off-by: Alexey Tikhonov <atikhono@redhat.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>

Thanks!


> ---
>  man7/unix.7 | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/man7/unix.7 b/man7/unix.7
> index e9edad467..71cdfc758 100644
> --- a/man7/unix.7
> +++ b/man7/unix.7
> @@ -331,7 +331,8 @@ This read-only socket option returns the
>  credentials of the peer process connected to this socket.
>  The returned credentials are those that were in effect at the time
>  of the call to
> -.BR connect (2)
> +.BR connect (2),
> +.BR listen (2),
>  or
>  .BR socketpair (2).
>  .IP
> -- 
> 2.41.0

Re: [PATCH] unix.7: SO_PEERCRED: Mention listen(2)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

Hi Kuniyuki, Alexey,

On Thu, Dec 21, 2023 at 10:49:11AM +0900, Kuniyuki Iwashima wrote:
> From: Alexey Tikhonov <atikhono@redhat.com>
> Date: Wed, 20 Dec 2023 18:28:34 +0100
> > In case of connected AF_UNIX stream sockets, server-side
> > credentials are set at the time of a call to listen(2),
> > not when client-side calls connect(2).
> > 
> > This is important if server side process changes UID/GID
> > after listen(2) and before connect(2).
> > 
> > Reproducer is available in https://bugzilla.redhat.com/show_bug.cgi?id=2247682
> > 
> > Behavior was confirmed in the email thread
> > https://lore.kernel.org/linux-man/CABPeg3a9L0142gmdZZ+0hoD+Q3Vgv0BQ21g8Z+gf2kznWouErA@mail.gmail.com/
> > 
> > Signed-off-by: Alexey Tikhonov <atikhono@redhat.com>
> 
> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
> 
> Thanks!

Thank you both for the patch and review!

Patch applied:
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=b34c2340657cfe467a0c2cde4933422bddf4348b>

Have a lovely day,
Alex

> > ---
> >  man7/unix.7 | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/man7/unix.7 b/man7/unix.7
> > index e9edad467..71cdfc758 100644
> > --- a/man7/unix.7
> > +++ b/man7/unix.7
> > @@ -331,7 +331,8 @@ This read-only socket option returns the
> >  credentials of the peer process connected to this socket.
> >  The returned credentials are those that were in effect at the time
> >  of the call to
> > -.BR connect (2)
> > +.BR connect (2),
> > +.BR listen (2),
> >  or
> >  .BR socketpair (2).
> >  .IP
> > -- 
> > 2.41.0

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]