Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 9 Aug 2002 09:50:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 9 Aug 2002 09:50:31 -0400 Received: from firewall.citel.com ([62.190.107.60]:64987 "EHLO cad.citel.com") by vger.kernel.org with ESMTP id ; Fri, 9 Aug 2002 09:50:30 -0400 Date: Fri, 9 Aug 2002 14:52:13 +0100 From: Michael Procter To: kuznet@ms2.inr.ac.ru Cc: linux-kernel@vger.kernel.org Subject: Re: Unix-domain sockets - abstract addresses Message-ID: <20020809145212.B1244@cad.citel.com> References: <20020808171524.A2469@cad.citel.com> <200208081836.WAA03110@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200208081836.WAA03110@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Thu, Aug 08, 2002 at 10:36:38PM +0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2419 Lines: 66 kuznet@ms2.inr.ac.ru wrote: > > > According to the man page 'unix(7)': > > When a socket is connected and it doesn't already have a local address a > > unique address in the abstract namespace will be generated automatically. > > This is wrong. The address is not autogenerated unless SO_PASSCRED > is requested by security&compatibility reasons. > So, if the socket is SOCK_DGRAM it is anounymous and "send-only", > it is impossible to reply to it. Why is the address not generated for 'security & compatibility' reasons? I've tried to think of a few reasons why this might be the case, but I can't come up with anything very convincing. I've been drawing parallels between PF_UNIX/SOCK_DGRAM and PF_INET/SOCK_DGRAM. From an interface point of view, they are very similar (to the extend my app cares), apart from this lack of automatic address generation for unix sockets. It seems odd that you can send a message to another process, and for the other end to have no way whatsoever of identifying the sender. The same situation in PF_INET doesn't exist - you get given a free port if you don't specify one by the time you connect(). > > but I have seen 0x0BA5, 0x7FA8, 0x1FA8 and others). > Yes, this is bug. The fix is enclosed. It should return nil address. Thanks for the patch (thanks also to Thunder who sent one for 2.5). However, there is still an inconsistency. The function unix_getname() will return just an address family if no address is present. Here is a diff that fixes this, and includes your change. --- af_unix.c.orig Fri Aug 9 14:10:05 2002 +++ af_unix.c Fri Aug 9 14:17:38 2002 @@ -1101,9 +1101,7 @@ unix_state_rlock(sk); if (!sk->protinfo.af_unix.addr) { - sunaddr->sun_family = AF_UNIX; - sunaddr->sun_path[0] = 0; - *uaddr_len = sizeof(short); + *uaddr_len = 0; } else { struct unix_address *addr = sk->protinfo.af_unix.addr; @@ -1385,7 +1383,7 @@ static void unix_copy_addr(struct msghdr *msg, struct sock *sk) { - msg->msg_namelen = sizeof(short); + msg->msg_namelen = 0; if (sk->protinfo.af_unix.addr) { msg->msg_namelen=sk->protinfo.af_unix.addr->len; memcpy(msg->msg_name, Regards, Michael Procter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/