running a daemon with userns in relocateble pack breaks

  • Done
  • quality assurance status badge
Details
2 participants
  • Jan Nieuwenhuizen
  • Ludovic Courtès
Owner
unassigned
Submitted by
Jan Nieuwenhuizen
Severity
important
J
J
Jan Nieuwenhuizen wrote on 27 Oct 2020 20:49
(address . bug-guix@gnu.org)
87blgn30w0.fsf@gnu.org
Hi!

As mentioned on IRC, running a daemon from a guix relocatable pack on a
foreign distro using the user namespace feature is troublesome: it looks
as if the daemon "loses" (its view of) the file-system once the parent
process that creates the daemon exits.

I'm attatching a package description for a test package "vork". It
builds a program "test" that forks the program "daemon".

The daemon program reads a character from /dev/urandom, prints it,
and sleeps for a second; 10 times.

The "test" parent program exits after 5 seconds. When the parent
program exits, the daemon crashes.

To reproduce, put "vork.scm" in a fresh directory and do something like:

Toggle snippet (9 lines)
fakeroot tar xf $(GUIX_PACKAGE_PATH=. guix pack --relocatable\
--symlink=/gnu/bin=bin guile shepherd vork --no-offload)
guix gc -D $(guix build -f vork.scm)
touch /tmp/daemon.log
tail -f /tmp/daemon.log &
GUILE_LOAD_COMPILED_PATH=$PWD/$(ls -1d gnu/store/*profile)/lib/guile/3.0/ccache\
:$PWD/$(ls -1d gnu/store/*profile)/lib/guile/3.0/site-ccache gnu/bin/test

this gives something like

Toggle snippet (15 lines)
.daemon-start
daemon: 10 ?
.daemon: 9 ?
.daemon: 8 T
.daemon: 7 ^O
.daemon: 6 O

exit
20:42:38 janneke@dundal:~/src/guix/master/vork [env]
$ 20:42:38 janneke@dundal:~/src/guix/master/vork [env]
$ Backtrace:
Exception thrown while printing backtrace:
In procedure public-lookup: Module named (system repl debug) does not exist

Greetings,
Janneke
Attachment: vork.scm
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
J
J
Jan Nieuwenhuizen wrote on 27 Oct 2020 21:09
(address . 44261@debbugs.gnu.org)(address . ludo@gnu.org)
875z6v2zz5.fsf@gnu.org
Jan Nieuwenhuizen writes:

Hi!

I tried the hint from Ludovic to use MS_PRIVATE in the attached patch
and that works for me; not sure if we want a test and even less sure how
to write that...

Janneke
From fd3104608c3fa6a2375b6c7df0862e5479976b39 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" <janneke@gnu.org>
Date: Tue, 27 Oct 2020 20:55:11 +0100
Subject: [PATCH] pack: Support running of daemons in user namespace-based
relocation.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

Add relocation via ld.so and fakechroot.

* gnu/packages/aux-files/run-in-namespace.c (bind_mount): Add 'MS_PRIVATE' to
avoid unmounting the bind mount when parent process exits.

Co-authored-by: Ludovic Courtès <ludo@gnu.org>
---
gnu/packages/aux-files/run-in-namespace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

Toggle diff (23 lines)
diff --git a/gnu/packages/aux-files/run-in-namespace.c b/gnu/packages/aux-files/run-in-namespace.c
index 52a16a5362..67cea4fcd5 100644
--- a/gnu/packages/aux-files/run-in-namespace.c
+++ b/gnu/packages/aux-files/run-in-namespace.c
@@ -1,5 +1,6 @@
/* GNU Guix --- Functional package management for GNU
Copyright (C) 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
+ Copyright (C) 2020 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
This file is part of GNU Guix.
@@ -138,7 +139,7 @@ bind_mount (const char *source, const struct dirent *entry,
close (open (target, O_WRONLY | O_CREAT));
return mount (source, target, "none",
- MS_BIND | MS_REC | MS_RDONLY, NULL);
+ MS_BIND | MS_PRIVATE | MS_REC | MS_RDONLY, NULL);
}
#if HAVE_EXEC_WITH_LOADER
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 30 Oct 2020 17:19
control message for bug #44261
(address . control@debbugs.gnu.org)
87a6w3y9dw.fsf@gnu.org
severity 44261 important
quit
L
L
Ludovic Courtès wrote on 30 Oct 2020 22:33
Re: bug#44261: running a daemon with userns in relocateble pack breaks
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 44261@debbugs.gnu.org)
871rhfxutl.fsf@gnu.org
Hello!

As discussed on IRC, my initial advice about MS_PRIVATE was misguided.
The real issue is the “rm_rf (new_root);” call, which removes the root
directory and thus leaves child processes (the daemon) with nothing.

The attached patch adds a test loosely based on yours and a fix for
that. The fix (for the “userns” engine) is to make NEW_ROOT a tmpfs,
such that upon completion, all we need to do is to unmount it and remove
it; it lives on as the root file system of child processes.

In the “fakechroot” case, we have to leave NEW_ROOT behind, which is not
great but acceptable (it’s user-owned, #o700, and it’s under /tmp). The
test only checks the “userns” engine.

If you confirm that it works for you and looks reasonable, we can apply
it.

Thanks,
Ludo’.
Attachment: file
J
J
Jan Nieuwenhuizen wrote on 30 Oct 2020 23:05
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 44261@debbugs.gnu.org)
877dr7s73f.fsf@gnu.org
Ludovic Courtès writes:

Hi!

Toggle quote (4 lines)
> As discussed on IRC, my initial advice about MS_PRIVATE was misguided.
> The real issue is the “rm_rf (new_root);” call, which removes the root
> directory and thus leaves child processes (the daemon) with nothing.

Yes, I'm not entirely sure what I thought to see yesterday; anyway the
rm_rf (new_root) is indeed the thing that makes the daemon crash.

Toggle quote (9 lines)
> The attached patch adds a test loosely based on yours and a fix for
> that. The fix (for the “userns” engine) is to make NEW_ROOT a tmpfs,
> such that upon completion, all we need to do is to unmount it and remove
> it; it lives on as the root file system of child processes.
>
> In the “fakechroot” case, we have to leave NEW_ROOT behind, which is not
> great but acceptable (it’s user-owned, #o700, and it’s under /tmp). The
> test only checks the “userns” engine.

Yes, I think this is acceptable.

Toggle quote (3 lines)
> If you confirm that it works for you and looks reasonable, we can apply
> it.

Yes, this works. The test and also my reproducer now work fine.

Thanks a lot!
Janneke

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 31 Oct 2020 23:19
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 44261-done@debbugs.gnu.org)
87blgirqbe.fsf@gnu.org
Hi,

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (2 lines)
> Ludovic Courtès writes:

[...]

Toggle quote (16 lines)
>> The attached patch adds a test loosely based on yours and a fix for
>> that. The fix (for the “userns” engine) is to make NEW_ROOT a tmpfs,
>> such that upon completion, all we need to do is to unmount it and remove
>> it; it lives on as the root file system of child processes.
>>
>> In the “fakechroot” case, we have to leave NEW_ROOT behind, which is not
>> great but acceptable (it’s user-owned, #o700, and it’s under /tmp). The
>> test only checks the “userns” engine.
>
> Yes, I think this is acceptable.
>
>> If you confirm that it works for you and looks reasonable, we can apply
>> it.
>
> Yes, this works. The test and also my reproducer now work fine.

Thanks for checking, I pushed the fix as
bfe82fe2f6e9f34c0774fe2114cdc7e937ba8bd2.

Ludo’.
Closed
J
J
Jan Nieuwenhuizen wrote on 1 Nov 2020 07:07
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 44261-done@debbugs.gnu.org)
87pn4x8v9o.fsf@gnu.org
Ludovic Courtès writes:

Hello,

Toggle quote (14 lines)
> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> If you confirm that it works for you and looks reasonable, we can apply
>>> it.
>>
>> Yes, this works. The test and also my reproducer now work fine.
>
> Thanks for checking, I pushed the fix as
> bfe82fe2f6e9f34c0774fe2114cdc7e937ba8bd2.

\o/

Thank you
Janneke.

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
Closed
?