[Pkg-sysvinit-devel] Bug#697003: initscripts: postinst fails: mv /dev/shm/* misses dot (hidden) files

[Roger Leigh]

On Sun, Dec 30, 2012 at 06:31:36PM +0000, Steven Chamberlain wrote:
> My jailed system's /dev is rather special (a sort of read-only devfs
> mount);  it doesn't contain a /dev/shm directory or link, and I'm not
> even able to create one as root.

Does /dev/shm exist on a standard kFreeBSD install?

> + ls -A /run/shm
> + [ .tmpfs !=  ]
> 
> This command indicates there is a file in this folder, called .tmpfs
> (though it isn't really a tmpfs), and so:

Why does this file exist here?  It should only be created by the
init scripts (mountkernfs) and even then it's only transient
during boot to prevent cleaning of the tmpfs.  AFAICS this should
not be present.

> + mv /run/shm/* /dev/shm
> mv: cannot stat `/run/shm/*': No such file or directory

> The wildcard does not match the .tmpfs file, and since there are no
> matching files this is an error.  Postinst fails.

OK.  This makes sense.  The question is really why this file
came to be present inside the directory.  While failing here is
certainly a bug, it's a failure mode which should never occur
in practice since .tmpfs should never be present on a running
system after boot.

> On the other hand, if there'd been some non-hidden files/directories
> there, they would be moved, but any remaining hidden ones would be
> deleted(!).

For the use case in question (in chroots) this is by design.
There is no use case for dotfiles in /dev/shm.

> Another problem is that if /dev/shm doesn't exist, and since a trailing
> slash wasn't used;  if my /dev had been writable and this command
> succeeded, it could place some directory from /run/shm there with
> arbitrary ownership/permissions, or some arbitrary link with scary
> consequences.
> 
> How about doing it this way instead - I think this is safer, complete,
> and even avoids races:
> 
> # find /run/shm -mindepth 1 -xdev -execdir mv \{\} /dev/shm/ \;

This is certainly safer.  However, we should be catering for this
already--we shouldn't be doing any modification of /dev if it's
a mountpoint of any sort.  Likewise we won't touch /dev/shm if it's
a mountpoint.

> Anyway;  why are we doing any of this?  In this (awkward) situation we'd
> ideally leave /run/shm contents where they are already, and /dev/shm
> must stay non-existent.

I think the crux of the question is whether we support /dev without
/dev/shm.  It's a glibc requirement.  Why is this directory not
present?  Or at least symlinked to /run/shm?  Currently we are making
the assumption that it will be present, and I'm not sure if that's
a bug or not.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800