kern/115619: Unfinished (uncompliant?) support for POSIX shared memory

[Ighighi]

>Number:         115619
>Category:       kern
>Synopsis:       Unfinished (uncompliant?) support for POSIX shared memory
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 19 08:50:01 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Ighighi
>Release:        6.2-STABLE
>Organization:
>Environment:
FreeBSD orion 6.2-STABLE FreeBSD 6.2-STABLE #0: Fri Aug 17 22:35:58 VET 2007     root at orion:/usr/obj/usr/src/sys/CUSTOM  i386
>Description:
Take a look at the minimalist file-based support in src/lib/libc/gen/posixshm.c:
http://www.FreeBSD.org/cgi/cvsweb.cgi/~checkout~/src/lib/libc/gen/posixshm.c

and the POSIX pages for shm_open() at shm_unlink():
http://www.opengroup.org/onlinepubs/000095399/functions/shm_open.html
http://www.opengroup.org/onlinepubs/000095399/functions/shm_unlink.html

Quoting the POSIX shm_open() page:
"If name begins with the slash character, then processes calling shm_open() with
the same value of name refer to the same shared memory object, as long as that
name has not been removed. If name does not begin with the slash character, the
the effect is implementation-defined. The interpretation of slash characters 
other than the leading slash character in name is implementation-defined."

The only portable way to create a POSIX shared memory object is using "/[^/]*"
(in regexp format) for names, but it's impossible in FreeBSD unless you're a
root user since it directly uses the root filesystem.  If, on the other hand,
we're the root user, the root filesystem must be mounted read/write and we'd
be somehow "violating" hier(7).

The next paragraph of the same POSIX shm_open says:
"The FD_CLOEXEC file descriptor flag associated with the new file descriptor is set."

This isn't currently done on FreeBSD.

>How-To-Repeat:

>Fix:
A possible solution for the first problem would be to dedicate a configurable
(via a sysctl() or getenv() or whatever) directory, at least for "/[^/]*" names,
that could be optionally mounted in memory for speed.  It is more or less like
/dev/shm on some Linux distros, but it could be done cleaner and better.

It appears Darwin implemented both shm_open() and shm_unlink() as system calls.
[Open]Solaris uses /tmp and tries to avoid a ENAMETOOLONG by using a MD5 hash of
the name and does the FD_CLOEXEC part.  See shm.c and pos4obj.[ch] at:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/rt/

An excerpt from pos4obj.c:
        /*
         * If the path is path_max - strlen(type) characters or less,
         * the name of the file to use will be the path prefixed by
         * the type.
         *
         * In the special case where the path is longer than
         * path_max - strlen(type) characters, we create a string based on the
         * MD5 hash of the path. We prefix that string with a '.' to
         * make it obscure, and create a directory in objroot with
         * that name. In that directory, we create a directory named
         * after the type of object requested.  Inside the type
         * directory, the filename will be the path of the object. This
         * prevents collisions in all namespaces.
         *
         * Example:
         * Let objroot = "/tmp/", path = "/<longpath>", and type = ".MQD"
         * Let the MD5 hash of "<longpath>" = "<hash>"
         *
         * The desired file is /tmp/.<hash>/.MQD/<longpath>
         */

I could help extend the current support through libc, any comments are welcome.
At the very least, the shm_open(3) manpage should contain a BUGS section warning
the user of these problems.  FWIW, most of this PR applies to DragonFly as well.


>Release-Note:
>Audit-Trail:
>Unformatted: