Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Aurelien Jarno <aurelien@aurel32.net>]

On 2018-12-12 10:06, Helmut Grohne wrote:
> Hi Aurelien,
> 
> On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:
> > 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.
> 
> 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.

(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

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net