From joek@zircon.staff.flyingcroc.net  Fri Dec 13 10:26:13 2002
Return-Path: <joek@zircon.staff.flyingcroc.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D9FDC37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 13 Dec 2002 10:26:13 -0800 (PST)
Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id DD77943ED4
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 13 Dec 2002 10:26:12 -0800 (PST)
	(envelope-from joek@zircon.staff.flyingcroc.net)
Received: from zircon.staff.flyingcroc.net (zircon.staff.flyingcroc.net [207.246.150.92])
	by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with SMTP id KAA71994
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 13 Dec 2002 10:26:12 -0800 (PST)
Received: (qmail 73923 invoked by uid 1001); 13 Dec 2002 18:26:12 -0000
Message-Id: <20021213182612.73922.qmail@zircon.staff.flyingcroc.net>
Date: 13 Dec 2002 18:26:12 -0000
From: Joe Kelsey <joek@zircon.staff.flyingcroc.net>
Reply-To: Joe Kelsey <joek@zircon.staff.flyingcroc.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: posix semaphore implementation errors
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         46239
>Category:       kern
>Synopsis:       posix semaphore implementation errors
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-standards
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Dec 13 10:30:01 PST 2002
>Closed-Date:    Sat Nov 17 07:05:11 UTC 2007
>Last-Modified:  Sat Nov 17 07:05:11 UTC 2007
>Originator:     Joe Kelsey
>Release:        FreeBSD 5.0
>Organization:
>Environment:
System: FreeBSD zircon.staff.flyingcroc.net 4.7-STABLE FreeBSD 4.7-STABLE #4: Mon Dec 2 10:11:39 PST 2002 joek@zircon.staff.flyingcroc.net:/usr/obj/usr/src/sys/ZIRCON i386

>Description:
	The new posix semaphore implementation in 5.0 has potential
	standards problems.
>How-To-Repeat:
	By inspection of code.

	Looking at src/lib/libc/sys/sem.c:
sem_t *
sem_open(const char *name, int oflag, ...)
{
	sem_t *sem;
	sem_t s;
	semid_t semid;
	mode_t mode;
	unsigned int value;

	mode = 0;
	value = 0;

	if ((oflag & O_CREAT) != 0) {
		va_list ap;

		va_start(ap, oflag);
		mode = va_arg(ap, int);
		value = va_arg(ap, unsigned int);
		va_end(ap);
	}
	/*
	 * we can be lazy and let the kernel handle the "oflag",
	 * we'll just merge duplicate IDs into our list.
	 */
	if (ksem_open(&semid, name, oflag, mode, value) == -1)
		return (SEM_FAILED);
...

	This clearly simply passes the name parameter to ksem_open.  We
	then examine src/sys/kern/uipc_sem.c:
static int
sem_create(td, name, ksret, mode, value)
	struct thread *td;
	const char *name;
	struct ksem **ksret;
	mode_t mode;
	unsigned int value;
{
	struct ksem *ret;
	struct proc *p;
	struct ucred *uc;
	size_t len;
	int error;

	DP(("sem_create\n"));
	p = td->td_proc;
	uc = p->p_ucred;
	if (value > SEM_VALUE_MAX)
		return (EINVAL);
	ret = malloc(sizeof(*ret), M_SEM, M_WAITOK | M_ZERO);
	if (name != NULL) {
		len = strlen(name);
		if (len > SEM_MAX_NAMELEN) {
			free(ret, M_SEM);
			return (ENAMETOOLONG);
		}
		/* name must start with a '/' but not contain one. */
		if (*name != '/' || len < 2 || index(name + 1, '/') != NULL) {
			free(ret, M_SEM);
			return (EINVAL);
		}
		ret->ks_name = malloc(len + 1, M_SEM, M_WAITOK);
		strcpy(ret->ks_name, name);
...

	It appears that names are restricted to a fixed length
	(SEM_MAX_NAMELEN, manifestly 14) and *must* start with '/' and
	not contain '/'.  This is in direct violation of the POSIX
	standard which says that the implementation must distinguish
	between names beginning or not beginning with '/', but otherwise
	the names must conform to pathname standards.

	The semaphore implementation should allow arbitrary pathnames as
	semaphore names.  In the future, the implementation should
	create empty files to stand-in for semaphores and coordinate
	with the file system code somehow.  For now, simply allowing
	longer semaphore names and not bothering with the whole '/'
	checking should suffice for POSIX.

>Fix:

	Remove the SEM_MAX_NAMELEN check.

	Remove the whole '/' checking stuff.



>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-standards 
Responsible-Changed-By: arved 
Responsible-Changed-When: Fri Aug 27 13:03:31 GMT 2004 
Responsible-Changed-Why:  
Over to standards to check, if we violate POSIX here. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=46239 

From: Wartan Hachaturow <wart@tepkom.ru>
To: Tilman Linneweh <arved@FreeBSD.org>
Cc: freebsd-bugs@FreeBSD.org, freebsd-standards@FreeBSD.org
Subject: Re: kern/46239: posix semaphore implementation errors
Date: Fri, 27 Aug 2004 17:54:38 +0400

 On Fri, Aug 27, 2004 at 01:05:15PM +0000, Tilman Linneweh wrote:
 > Over to standards to check, if we violate POSIX here.
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=46239
 
 IEEE Std 1003.1, 2004 Edition:
 
 "The name argument points to a string naming a semaphore object. It is
 unspecified whether the name appears in the file system and is visible
 to functions that take pathnames as arguments. The name argument
 conforms to the construction rules for a pathname. If name begins with
 the slash character, then processes calling sem_open() with the same
 value of name shall refer to the same semaphore object, as long as that
 name has not been removed. 
 
 If name does not begin with the slash
 character, the effect is implementation-defined. The interpretation of
 slash characters other than the leading slash character in name is
 implementation-defined."
 
 Standart defines only the leading "/" behaviour, and leaves other places
 of slash for the implementation to define. We define it like "we disallow
 slashes in other places". We even document it in BUGS section of the
 manpage :)
 
 -- 
 Regards, Wartan.
 "Be different: conform."
State-Changed-From-To: open->feedback 
State-Changed-By: kmacy 
State-Changed-When: Sat Nov 17 07:03:47 UTC 2007 
State-Changed-Why:  

Is this issue still present? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=46239 
State-Changed-From-To: feedback->closed 
State-Changed-By: kmacy 
State-Changed-When: Sat Nov 17 07:04:37 UTC 2007 
State-Changed-Why:  

Closed due to age, changes to the underlying code, and submitter mail bounces. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=46239 
>Unformatted:
