[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d3b98744dfe0ad0f276239b67e84c26c88aa03e.camel@redhat.com>
Date: Tue, 22 Aug 2023 10:43:06 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>, kuba@...nel.org
Cc: davem@...emloft.net, edumazet@...gle.com, kuni1840@...il.com,
netdev@...r.kernel.org
Subject: Re: [PATCH v1 net] net: Allow larger buffer than peer address for
SO_PEERNAME.
On Mon, 2023-08-21 at 19:40 -0700, Kuniyuki Iwashima wrote:
> From: Jakub Kicinski <kuba@...nel.org>
> Date: Mon, 21 Aug 2023 19:11:13 -0700
> > On Fri, 18 Aug 2023 17:55:52 -0700 Kuniyuki Iwashima wrote:
> > > For example, we usually do not know the peer name if we get an AF_UNIX
> > > socket by accept(), FD passing, or pidfd_getfd(). Then we get -EINVAL
> > > if we pass sizeof(struct sockaddr_un) to getsockopt(SO_PEERNAME). So,
> > > we need to do binary search to get the exact peer name.
> >
> > Sounds annoying indeed, but is it really a fix?
>
> So, is net-next preferable ?
>
> I don't have a strong opinion, but I thought "Before knowing the peer
> name, you have to know the length" is a bug in the logic, at least for
> AF_UNIX.
I'm unsure we can accept this change: AFAICS currently
getsockopt(SO_PEERNAME,... len) never change the user-provided len on
success. Applications could relay on that and avoid re-reading len on
successful completion. With this patch such application could read
uninitialized data and/or ever mis-interpret the peer name len.
If the user-space application want to avoid the binary search, it can
already call getpeername().
Cheers,
Paolo
Powered by blists - more mailing lists