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

[Roger Leigh]

On Sun, Dec 30, 2012 at 08:29:51PM +0000, Steven Chamberlain wrote:
> Control: severity -1 minor
> 
> On 30/12/12 19:07, Roger Leigh wrote:
> > Does /dev/shm exist on a standard kFreeBSD install?
> 
> It gets created by initscripts as symlink to /run/shm.  Otherwise it
> would not be there;  apparently Linux 2.6 invented it and it didn't seem
> too popular with upstream FreeBSD.
> 
> > It's a glibc requirement.
> 
> I didn't know this.  Software running in the jails fortunately seems to
> be using /run/shm properly.

It won't be; this isn't a "Linux" thing; it's just the directory used
to create POSIX shared memory with the shm_open() function, which is
typically a tmpfs mount so it's in-memory.  glibc uses /dev/shm still,
so you need a symlink /dev/shm->/run/shm or else it won't work at all.

> Within jails, I cannot write to /dev (even as root) so shm cannot be
> created as a directory or symlink.  But as an alternative I can create
> it from the host system before booting, so that will do as a workaround
> and for compatibility.

I think this is the best way to do it.  Either as a symlink or a
mount you share with the jail.

> >> + 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's timestamped from when the jailed system booted, which would have
> been with initscripts 2.88dsf-32.
> 
> It seems to be created by mount_shm in mount-functions.sh.  Is it
> missing from the cleanup here in bootmisc?
> 
> # Remove bootclean's flag files.
> # Don't run bootclean again after this!
> rm -f /tmp/.clean /lib/init/rw/.clean /run/.clean /run/lock/.clean
> rm -f /tmp/.tmpfs /lib/init/rw/.tmpfs /run/.tmpfs /run/lock/.tmpfs
> 
> While here - could neaten this up a little:
> 
> for dir in /lib/init/rw /tmp /run /run/lock /run/shm; do
> 	rm -f "$dir/.clean" "$dir/.tmpfs"
> done

That's much better, thanks.

> >> 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.
> 
> In that case, the "ls -A" flag is unnecessary?  A plain "ls" would
> determine if anything in that directory needs keeping.  And the error
> with "mv" would be avoided.

I'll have to double check the shm_open API.  You probably could
abuse it with leading dots in the shared memory names.  The main
existing abusers were /dev/.udev and /dev/.mdadm, but these only
apply to the host system, not to chroots.  We should probably
cater for it happening for robustness in any case.

> > 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.
> 
> I'm not sure exactly what you mean by modification, but at least for the
> mmdd|mddd cases it will try to move files to /dev/shm

Yes.  In this case we won't make/mount anything new but we will make
use of the existing directories/mounts.  And symlink /run/shm to
/dev/shm since doing it the other way around is impossible without
causing dataloss (chroots only, since we have no control over what
was mounted, and we can't risk deleting anything shared with the
host).

> Maybe it's not a realistic situation, but since there is no trailing
> slash, if /dev/shm didn't exist, a malicious user could have created in
> advance:
> 
> 1. a symlink /run/shm/oops -> /etc (which gets placed first as /dev/shm)
> 2. regular file /run/shm/passwd (which gets written over /etc/passwd)

It's certainly possible if /dev/shm is missing, which we were
assuming would never be the case.  Updating the script to take
this possibility into account will certainly be done.

> > Currently we are making
> > the assumption that it will be present, and I'm not sure if that's
> > a bug or not.
> 
> I'm not sure either.  The above issue poses a security risk, so I'd
> consider adding a trailing slash (so that "mv" fails with an error
> instead);  I guess it is unlikely though and so needn't be fixed with
> any urgency.

This makes sense, and I'll change this, thanks.  It'll have to be
after new year now, though.


Thanks,
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