shm_open() pathname interpretation
lassi at lassi.io
Wed May 1 09:16:24 PDT 2019
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
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
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..
More information about the Users