Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)
On Fri, 13 Jan 2017 at 14:14:09 +0000, Holger Levsen wrote:
> how should /dev/shm be mounted? and how /run/shm?
I believe the "API" is that /dev/shm is either a tmpfs with
/tmp-like permissions (01777), or a symlink to such a tmpfs.
My understanding is that /run/shm is considered to be an
implementation detail, rather than something that software should
hard-code anywhere.
Reference: glibc sysdeps/unix/sysv/linux/shm-directory.c (the original
user of /dev/shm).
systemd mounts a tmpfs on /dev/shm (it's hard-coded in as one of
the "API filesystems"), and Debian's systemd packaging puts a symlink
at /run/shm in case anything is relying on it
(/usr/lib/tmpfiles.d/debian.conf).
If I'm reading the initscripts code correctly, sysvinit does the reverse
by default, for some reason (/run/shm is the mount point and /dev/shm the
symlink). I think the motivation might have been to be able to use the
same tmpfs for /run and /run/shm, but that's a bad idea if you want to
prevent unprivileged users from performing a DoS attack on privileged system
components by filling up /run (which is why systemd gives each user their
own tmpfs at /run/user/$uid by default).
The default schroot configuration mounts a tmpfs on /dev/shm and does not
do anything special about /run/shm.
Generalizing from those, I think it's reasonable to say that in a
bare-metal system, init is responsible for arranging for /dev/shm to be
as required, and in a container or chroot, the container manager is
responsible.
S
Reply to: