From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id 40AC43858D38 for ; Mon, 6 Feb 2023 17:21:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40AC43858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9D0EF32003CE for ; Mon, 6 Feb 2023 12:21:26 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Mon, 06 Feb 2023 12:21:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1675704086; x=1675790486; bh=T9aTvlJIg/ yBP1/ToK8dU9q60KxkVmg3srQC0QrGsus=; b=YguVgYfBzEQ3r1Tc30xifv2I9N ctgCOY/INJadWRkDGhBKp9hg6QeaVycE4U2qkPo+LF5Z8aZhPBa9ZkIbgGj/I6qy aFVCcfZOwmvpyzIzaSZsGuJDVLGEmjazsTDPP1z3HgNo4ATQV8fz5CzoPiVT6Vsz OoVFlIMw6mJ6JEd8Jw/Qi60MQGz6tCObUPwHkKoAJD6BD4ZJA0iYs78cNlBqyvX8 WX3JlV1CHNxjYSuMLGYFacU7+OiK6X8WOw2UklpzoxG2kvGCTzyJZb8gIBHkuVY+ QE4QDzHJT+GjzUFDhNYrCkb9HF+YAA/Qxg96UwiQ3gLO3Cp9Toe+vfxUo7+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1675704086; x=1675790486; bh=T9aTvlJIg/yBP1/ToK8dU9q60Kxk Vmg3srQC0QrGsus=; b=Dcc43DZNRirT0YuhuX/5B3mxdS73WWqxuIfB45hgInIR WaiztoxRn8EVL61XS5LDXnZSK/zKTVqSEe506HEFfljQzeKh3opeFTxApEAQWGdC ZxYOrSsocEnHtTyNNTOK5jroTTelBgV1qifKUcLPr/JT7wTVgr+JaxOtM/m4ljFG Sszf7ABle3ZCuNbPSLBnBdm24mynBvKlGbt5HykGBAsMC6ICpR08lJUHW17znGW1 AqF8axUgV7Tjti7ai2QFKGu5Yw4Hx1mhCUimVmELXbEE2xz2/J8VgytNhvBLlBxs d1y6rjw3k6iDtbnjIeUWsI86ABnR6bZlnu4ykK6bKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudegiedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpefhuefhveeuffetfffgjeetgfekkeehfedtfeelgfehffffveehkeel fefgheffudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 078F1272007A; Mon, 6 Feb 2023 12:21:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-108-ge995779fee-fm-20230203.001-ge995779f Mime-Version: 1.0 Message-Id: <6de0523f-623b-49ed-af84-1f8e026f6244@app.fastmail.com> In-Reply-To: <9998a4eb-528b-b006-ebeb-d94816e62d82@gmail.com> References: <20230205152835.17413-1-alx@kernel.org> <0a9306fa37edeb4a989b2929de67fee8606a3d8a.camel@xry111.site> <20230206133850.GI3298@brightrain.aerifal.cx> <9998a4eb-528b-b006-ebeb-d94816e62d82@gmail.com> Date: Mon, 06 Feb 2023 12:21:03 -0500 From: "Zack Weinberg" To: "GNU libc development" Subject: Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union Content-Type: text/plain X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Feb 6, 2023, at 9:11 AM, Alejandro Colomar via Libc-alpha wrote: > On 2/6/23 14:38, Rich Felker wrote: >> There is absolutely not any need to declare the union for application >> code calling the socket APIs. You declare whatever type you will be >> using. For binding or connecting a unix socket, sockaddr_un. For IPv6, >> sockaddr_in6. Etc. Then you cast the pointer to struct sockaddr * and >> pass it to the function. > > Except that you may be using generic code that may use either of AF_UNIX, > AF_INET, and AF_INET6. A web server may very well use all the three. I have personally tripped over systems where struct sockaddr_un was _bigger_ than struct sockaddr_storage. Also, AFAIK modern kernels (not just Linux) do not actually impose a 108-byte (or whatever) limit on the length of sun_path; application code can treat the structure definition as being struct sockaddr_un { sa_family_t sun_family; char sun_path[]; // C99 flexible array member }; as long as the `addrlen` parameter to whatever system call you're using accurately reflects the size of the address object you passed in. Kind of the same as how you can make your own bigger fd_set to call select() with, if you want. Point being, even if sockaddr_storage is bigger than the _default_ sockaddr_un, that still might not be big enough. I'd also like to point out that none of these structures can change size without breaking ABI compatibility. In particular, namespace issues aside, glibc _cannot_ make the definition of struct sockaddr be either struct sockaddr { sa_family_t sa_family; }; or struct sockaddr { union { // ... struct sockaddr_in6 in6; }; }; because a variable declaration `struct sockaddr sa;` must allocate 16 bytes of space -- no more and no less. > However, there are some APIs that require you to allocate an object. For > example recvfrom(2). How would you recommend using recvfrom(2) Well, most address families have fixed-size addresses: if you called socket(AF_INET6, SOCK_DGRAM, 0) then you know recvfrom on that socket needs enough space for struct sockaddr_in6. If you receive a socket descriptor as an argument and you don't know its address family, you can use `getsockopt(sock, SOL_SOCKET, SO_DOMAIN)` to look it up. This won't work for AF_UNIX, though. recvfrom() _will_ tell you if you didn't give it enough space (by updating `addrlen` to a bigger number than you passed in); it's not idempotent, so you can't call it again, but you _could_ call getpeername() instead. In principle you could have a connectionless (SOCK_DGRAM) AF_UNIX socket and then getpeername() wouldn't work, but does anyone actually _want_ the peer address when serving from an AF_UNIX socket, as opposed to the SCM_CREDENTIALS ancillary message or the SO_PEERCRED sockopt query? zw