Greetings. I'm running jessie with several chroots created with
schroot. As a normal user, I do this:

schroot -c sid
diffoscope some.deb someother.deb

and this is the result:

CRITICAL /dev/shm is not available or not on a tmpfs. Unable to create semaphore.

I believe such error is not supposed to happen.

Thanks.

Well, quite a lot of stuff requires shm nowadays.

Consider that we rb people run diffoscope inside scrhoot, and it just
works.  We have

    /dev/shm    /dev/shm    none    rw,bind     0   0

in /etc/schroot/default/fstab.


Personally I'd not consider this a diffoscope bug.

The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
this is not done for the default flavour as too options are possible
there:
- Bind mount like above. This means sharing the shm directory with the
  outside world. This might have some security implications, and
  unwanted consequences.
- Empty tmpfs like for buildds. This means the processes do not have
  accesses to shared memory from processes outside of the chroot.

Depending on how the user want to use schroot, one or the other
configuration should be used. I don't know how we should choose the
default one.

Hi Aurelien,

Essentially, we have three options (for the default and desktop
profiles) now:

(A) Status quo: Don't mount /dev/shm.
(B) Bind mount /dev/shm.
(C) Mount a tmpfs on /dev/shm.

As you point out, each of (B) and (C) breaks some people's workflows
(either isolation or stuff doesn't work).

Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
itch, ...) want. (C) doesn't regress on isolation compared to (A).
Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.

I agree that we cannot find a one-fits-all here. Having a comment in the
fstab for the other option certainly helps (and is already there). Still
changing the default from (A) to (C) seems like it could fix a fair
number of use cases without regressing assumptions on isolation or
existing use cases.

Does that make sense to you?

Helmut

(C) might give users the possibility to trigger an OOM and DoS system.
/dev/shm is writable by any user. If users have no limit on the number
of chroots they can run, they might be able to fill the whole memory
(RAM + swap), leading to an OOM, potentially killing essential services
as the memory from a tmpfs can't be killed. This does not happen on a
normal system, as the default size of a tmpfs is half of the size of the
RAM.

So I am not sure that (C) is "strictly better".

Aurelien

It should perhaps be combined with some sensible default size
limitations like we used to provide in (IIRC) /etc/default/tmpfs.

For the (B) case, do we have any defined use case for sharing shm
between host and chroot?  It's useless for anonymous (unlinked)
mappings, because they won't be propagated.  So the only use case is
named mappings.  If we don't have any concrete use case for that, I'd be
tempted to drop this possibility entirely.

For (A) if you don't mount /dev/shm, is there still some risk due to
using the underlying devtmpfs mount and causing problems, including
security problems, as a result?  You might still get shared data between
host and chroots stored there, which might have security and privacy
implications?  And you could affect the /dev mountpoint if using all the
space prevents device node or other file creation under /dev on the host?

I think (C) is vastly preferable from the security point of view.
However, it does as you point out, have problems if you overcommit
resources across multiple chroots.

One possible mitigation would be to not mount a tmpfs at all.  There is
no technical requirement that /dev/shm be a tmpfs.  It could be backed
by disk, e.g. creating and bind mounting chroot/shm to chroot/dev/shm
would make it use the same disc backing as the chroot itself.  Or create
a session-specific private dir under [/var]/tmp and bind mount that (it
will avoid serialising and storing session state for source chroots).
There will of course be a potential performance cost in using a real
disc, but it takes all of the resource exhaustion and privacy questions
completely out of the picture.


Regards,
Roger

Hi,

I'd like to add here that I just ran into this in a different way. I do my
development in profile=destkop chroots which are also missing the /dev/shm
line in fstat like the default profile.

In my case upstream was using faketime(1) to tame some unreproducibility,
but this needs access to /dev/shm to function at all. Curiously the
permissions of /dev/shm were such that only root could write there:

    (unstable-amd64-dekstop):~$ ls -ld /dev/shm
    drwxr-xr-x 2 root root 40 Oct 16 10:36 /dev/shm

Adding the fstab line fixes this as tmpfs seems to set the mount point to
mode 777.

FYI: I build my sbuild and "desktop" chroots with sbuild-createchroot(8).