Re: git: 943c446629e3 - main - Revert "libc: Some enhancements to syslog(3)"
- In reply to: Gleb Smirnoff : "Re: git: 943c446629e3 - main - Revert "libc: Some enhancements to syslog(3)""
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 02 Dec 2021 21:10:10 UTC
On Thu, Dec 2, 2021 at 2:01 PM Gleb Smirnoff <glebius@freebsd.org> wrote: > > On Tue, Nov 30, 2021 at 06:12:42PM +0000, Alan Somers wrote: > A> Revert "libc: Some enhancements to syslog(3)" > A> > A> This reverts commit 2886c93d1bca231260ebc01d4205743ca781f3c7. > A> The original commit has two problems: > A> > A> * It sets SO_SNDBUF to be as large as MAXLINE. But for unix domain > A> sockets, the send buffer is bypassed. Packets go directly to the > A> peer's receive buffer, so setting and querying SO_SNDBUF is > A> ineffective. To ensure that the socket can accept messages of a > A> certain size, it would be necessary to add a SO_PEERRCVBUF socket > A> option that could query the connected peer's receive buffer size. > > I'd rather say we don't need SO_PEERRCVBUF. The SO_SNDBUF on AF_UNIX > should transparently to the application look and report peer's receive buffer. > > -- > Gleb Smirnoff That would work too. But the devil is in the details. Would the socket buffer's size be adjustable via both endpoints? Are there any security or setrlimit issues in allowing an unprivileged client to change the socket buffer size of its connected privileged peer?