Handling unshare() and kernel namespaces

Robert O'Callahan robert at ocallahan.org
Fri Apr 17 04:50:41 UTC 2015

On Fri, Apr 17, 2015 at 4:44 AM, Chris Jones <jones.chris.g at gmail.com>

> On Thu, Apr 16, 2015 at 4:40 AM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
>> However, during replay the directory chroot()ed to doesn't exist, because
>> it's created and unlinked during the recording, so it seems to me we can't
>> execute the chroot() after all.
> The directory might not exist in the sandbox case, but programs like
> apache can also chroot to well-known system directories (or at least could
> in the past). ​ This feels similar to our copy-or-not-copy mmap heuristics:
> if the chroot dir is user-writeable, we ought to "copy" it (see below), and
> if it's a system dir, optimistically assume it won't meaningfully change.
> Then during replay, on a chroot to a non-copied dir we would just execute
> it, and on a chroot to a copied dir we could create a new tmp dir in our
> emufs like we do for copied mmap files and then execute the chroot.  (We
> would need to preserve identity because theoretically multiple processes
> could chroot into the same dir.)
> ​But of course we wouldn't want to try preserving arbitrary fs layouts in
> the copied dirs, so we can probably stipulate for now that on a chroot into
> a user-writeable ​dir, the dir must be empty.  (Maybe with an exception or
> two TBD.)  But if we make that stipulation, for that case it becomes less
> important to actually execute the chroot during replay.  So we could take
> whichever approach looks simpler.

I don't think there is any need to actually execute a chroot during replay
(ignoring the exec case, as we've agreed to do :-) ). Maybe I'm missing

BTW the /proc/<tracer-pid>/fd/N trick that we use to expose file names for
temporary files to the tracee doesn't work for sandboxed tracees, even with
the backdoor-root-fd being used. The problem is that the /proc/pid/fd
directory is dr-x------, and there's nothing we can do about that, so a
process in a new user namespace can't traverse that directory to read
anything under it. I think we'll have to pass the non-proc filenames for
these files to the tracee.

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20150417/c9d245d7/attachment.html>

More information about the rr-dev mailing list