shm_open() pathname interpretation

[Lassi Kortela]

DragonFly's shm_open() implementation in <lib/libc/gen/posixshm.c> uses 
the special FPOSIXSHM fcntl() flag to ensure a memory-backed file for 
the shm object. However, it first uses an ordinary open() to get the fd 
on which it sets this flag. This means that regular pathname 
interpretation rules are used for access control on the name passed to 
shm_open().

While this behavior is POSIX-compliant it differs significantly from 
other operating systems.

Other BSDs, Linux (GNU libc) and Solaris preprocess the pathname so it 
goes under a special shm directory where a memory-backed file system is 
mounted. For example, shm_open("/foo", ...) gets translated into 
"/some/tmp/fs/foo". So pathnames of the form "/foo" (i.e. a slash 
followed by some name without slashes) work. While DragonFly's 
interpretation is consistent on its own, it forbids this common pathname 
form (unless the user is root and hence has permission to write to the 
file system root directory, in which case the name "foo" is created 
there -- probably also undesirable).

Some operating systems (NetBSD, possibly FreeBSD) require an initial 
slash in the pathname and forbid further slashes, so "/foo" is probably 
the most portable form of a pathname that can be passed into these 
functions. In light of this, would it make sense to consider an 
alternative interpretation for shm pathnames (putting them inside a 
special directory or in a separate namespace distinct from the ordinary 
file system)?

The easiest workaround for portable code right now is to use "/tmp/foo" 
instead of "/foo" as a special case for DragonFly, but it's the only OS 
I've found where "/foo" does not work.

For reference, I have some shm code portable to 8 operating systems at 
<https://github.com/lassik/shm_open_anon>. There are an insane amount of 
notes in the README and some remarks are still missing from it so the 
topic is quite complex..

KR,
lassi