Bug#276138: marked as done (sys/un.h: SUN_LEN cannot be used in abstract namespace)
Your message dated Tue, 12 Oct 2004 18:37:02 +0900
with message-id <81zn2stgzl.wl@omega.webmasters.gr.jp>
and subject line Bug#276138: sys/un.h: SUN_LEN cannot be used in abstract namespace
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 12 Oct 2004 08:34:09 +0000
>From chm@c00.info Tue Oct 12 01:34:08 2004
Return-path: <chm@c00.info>
Received: from mxfep02.bredband.com [195.54.107.73]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CHI6i-0006DS-00; Tue, 12 Oct 2004 01:34:08 -0700
Received: from wire.hn.org ([213.112.90.247] [213.112.90.247])
by mxfep02.bredband.com with SMTP
id <[🔎] 20041012083300.JPUI1752.mxfep02.bredband.com@wire.hn.org>;
Tue, 12 Oct 2004 10:33:00 +0200
Received: by wire.hn.org (sSMTP sendmail emulation); Tue, 12 Oct 2004 10:32:55 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: =?iso-8859-1?q?Christian_H=E4ggstr=F6m?= <chm@c00.info>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: sys/un.h: SUN_LEN cannot be used in abstract namespace
Bcc: =?iso-8859-1?q?Christian_H=E4ggstr=F6m?= <chm@c00.info>
X-Mailer: reportbug 2.99.3
Date: Tue, 12 Oct 2004 10:32:55 +0200
Message-Id: <[🔎] 20041012083300.JPUI1752.mxfep02.bredband.com@wire.hn.org>
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Package: libc6-dev
Version: 2.3.2.ds1-17
Severity: minor
File: /usr/include/sys/un.h
The man-page unix(7) describes abstract namespace as follows.
sun_family always contains AF_UNIX. sun_path contains the zero-termi-
nated pathname of the socket in the file system. If sun_path starts
with a zero byte it refers to the abstract namespace maintained by the
Unix protocol module. The socket's address in this namespace is given
by the rest of the bytes in sun_path. Note that names in the abstract
namespace are not zero-terminated.
The macro SUN_LEN currently is defined as
#define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path) + strlen ((ptr)->sun_path))
I suggest that a check should be made for a zero first byte, and in that
case return sizeof(struct sockaddr_un), as the manpage says.
If it is the programmers responsibility to check for abstract
namespace, I suggest adding a comment about that close to the
definition of SUN_LEN.
Thanks!
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8.1
Locale: LANG=sv_SE, LC_CTYPE=sv_SE
Versions of packages libc6-dev depends on:
ii libc6 2.3.2.ds1-17 GNU C Library: Shared libraries an
ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme
-- no debconf information
---------------------------------------
Received: (at 276138-done) by bugs.debian.org; 12 Oct 2004 09:37:04 +0000
>From gotom@debian.or.jp Tue Oct 12 02:37:03 2004
Return-path: <gotom@debian.or.jp>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CHJ5b-0002rZ-00; Tue, 12 Oct 2004 02:37:03 -0700
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id 9B3B2DEB5F; Tue, 12 Oct 2004 18:37:02 +0900 (JST)
Date: Tue, 12 Oct 2004 18:37:02 +0900
Message-ID: <81zn2stgzl.wl@omega.webmasters.gr.jp>
From: GOTO Masanori <gotom@debian.or.jp>
To: Christian =?ISO-8859-1?Q?H=E4ggstr=F6m?= <chm@c00.info>,
276138-done@bugs.debian.org
Subject: Re: Bug#276138: sys/un.h: SUN_LEN cannot be used in abstract namespace
In-Reply-To: <[🔎] 20041012083300.JPUI1752.mxfep02.bredband.com@wire.hn.org>
References: <[🔎] 20041012083300.JPUI1752.mxfep02.bredband.com@wire.hn.org>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
(i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Delivered-To: 276138-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
At Tue, 12 Oct 2004 10:32:55 +0200,
Christian H=E4ggstr=F6m wrote:
> The man-page unix(7) describes abstract namespace as follows.
>=20
> sun_family always contains AF_UNIX. sun_path contains the zero-termi-
> nated pathname of the socket in the file system. If sun_path starts
> with a zero byte it refers to the abstract namespace maintained by the
> Unix protocol module. The socket's address in this namespace is given
> by the rest of the bytes in sun_path. Note that names in the abstract
> namespace are not zero-terminated.
>=20
> The macro SUN_LEN currently is defined as
>=20
> #define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path) + s=
trlen ((ptr)->sun_path))
This SUN_LEN macro was introduced in BSD 4.3 Reno.
> I suggest that a check should be made for a zero first byte, and in that
> case return sizeof(struct sockaddr_un), as the manpage says.
Documents does not say about such things. I strongly object your
idea.
> If it is the programmers responsibility to check for abstract
> namespace, I suggest adding a comment about that close to the
> definition of SUN_LEN.
Why? I don't see any reasons to add such comments.
Regards,
-- gotom
Reply to: