unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* /dev/shm inconsistency in chroot
@ 2014-01-23 19:21 Sree Harsha Totakura
  2014-01-23 19:56 ` Mark H Weaver
  0 siblings, 1 reply; 10+ messages in thread
From: Sree Harsha Totakura @ 2014-01-23 19:21 UTC (permalink / raw)
  To: guix-devel, nix-dev


[-- Attachment #1.1.1: Type: text/plain, Size: 2222 bytes --]

Hi,

It has been known for a while that any access to /dev/shm fails inside
chroot if the host system has /dev/shm symlinked to /run/shm.

The suggested method to deal with this until now is to remove the
symlink from the host system, create /dev/shm directory and mount a
tmpfs on it.

I spent sometime investigating why this is needed and here are some
points I noted: from libstore/build.cc the daemon tries to bind mount
some paths from the host system into the chroot directory.  Among these
are /dev and /dev/pts.  The daemon also mounts a tmpfs file system under
chrootdir+/dev/shm should the path /dev/shm exist.

Due to bind mounting /dev, on systems where /dev/shm is a symlink, the
symlink is also present in the chrootdir+/dev.  Since the symlink points
to /run/shm, and since /run is not bind mounted by default into the
chrootdir+/run, the symlink is broken inside chroot.

The above problem can be addressed by passing --chroot-directory=/run to
the guix-daemon which then includes /run into the list of mounts that
are to be bind mounted inside chroot.  This will resolve the
chroot+/dev/shm symlink properly.  Yet, the accesses to /dev/shm fail
inside the chroot.  This is because the mount statement in build.cc for
mounting tmpfs at chroot+/dev/shm mounts the tmpfs at /run/shm the
target of the symlink and since /run tree is made private the mount does
not propagate into the bind mounted chroot+/run tree.  In the chroot,
this leaves the /dev/shm symlink to point to the directory /run/shm and
obviously any shared memory accesses fail.

This problem can be fixed finally by passing
--chroot-directory=/run/shm.  Although the tmpfs mount for
chroot+/dev/shm still ends up mounting tmpfs at /run/shm, since /run/shm
is now bind mounted to chroot+/run/shm, inside the chroot the symlink
/dev/shm points to /run/shm which is now a tmpfs.  The shared memory
accesses work fine here.  However there is caveat: since /run/shm is
bindmounted any files from the host system from that directory are also
present in the chroot.

To address this further and to get rid of having the user to pass
--chroot-directory flag, I propose the attached patch.

Regards,
Sree

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: 0001-Create-tmpfs-on-dev-shm-after-chrooting.patch --]
[-- Type: text/x-patch; name="0001-Create-tmpfs-on-dev-shm-after-chrooting.patch", Size: 2198 bytes --]

From 359fda36b6dcabea79a76b56e10d4d67702f545f Mon Sep 17 00:00:00 2001
From: Sree Harsha Totakura <sreeharsha@totakura.in>
Date: Thu, 23 Jan 2014 20:11:57 +0100
Subject: [PATCH] Create tmpfs on /dev/shm after chrooting.

src/libstore/build.cc: Create tmpfs on /dev/shm after chrooting.  If /dev/shm is a link, create required directory for mounting.
---
 src/libstore/build.cc |   17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/libstore/build.cc b/src/libstore/build.cc
index 4329d9a..b01bf92 100644
--- a/src/libstore/build.cc
+++ b/src/libstore/build.cc
@@ -2054,12 +2054,6 @@ void DerivationGoal::initChild()
             if (mount("none", (chrootRootDir + "/proc").c_str(), "proc", 0, 0) == -1)
                 throw SysError("mounting /proc");
 
-            /* Mount a new tmpfs on /dev/shm to ensure that whatever
-               the builder puts in /dev/shm is cleaned up automatically. */
-            if (pathExists("/dev/shm"))
-                if (mount("none", (chrootRootDir + "/dev/shm").c_str(), "tmpfs", 0, 0) == -1)
-                    throw SysError("mounting /dev/shm");
-
             /* Do the chroot().  Below we do a chdir() to the
                temporary build directory to make sure the current
                directory is in the chroot.  (Actually the order
@@ -2067,6 +2061,17 @@ void DerivationGoal::initChild()
                tmpRootDit/tmpDir are the same directories.) */
             if (chroot(chrootRootDir.c_str()) == -1)
                 throw SysError(format("cannot change root directory to `%1%'") % chrootRootDir);
+
+            /* Mount a new tmpfs on /dev/shm to ensure that whatever
+               the builder puts in /dev/shm is cleaned up automatically. */
+            if (pathExists ("/dev/shm"))
+            {
+                Path target = "/dev/shm";
+                if (isLink(target) && !pathExists(target = readLink(target)))
+                    createDirs(target);
+                if (mount("none", "/dev/shm", "tmpfs", 0, 0) == -1)
+                    throw SysError("mounting /dev/shm");
+            }
         }
 #endif
 
-- 
1.7.10.4


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: /dev/shm inconsistency in chroot
  2014-01-23 19:21 /dev/shm inconsistency in chroot Sree Harsha Totakura
@ 2014-01-23 19:56 ` Mark H Weaver
  2014-01-24 10:16   ` Sree Harsha Totakura
  0 siblings, 1 reply; 10+ messages in thread
From: Mark H Weaver @ 2014-01-23 19:56 UTC (permalink / raw)
  To: sreeharsha; +Cc: guix-devel, nix-dev

Hi,

Sree Harsha Totakura <sreeharsha@totakura.in> writes:

> It has been known for a while that any access to /dev/shm fails inside
> chroot if the host system has /dev/shm symlinked to /run/shm.
>
> The suggested method to deal with this until now is to remove the
> symlink from the host system, create /dev/shm directory and mount a
> tmpfs on it.

[...]

> The above problem can be addressed by passing --chroot-directory=/run to
> the guix-daemon which then includes /run into the list of mounts that
> are to be bind mounted inside chroot.

This proposal would take us in the wrong direction.  We should not solve
this problem by inheriting more directories from the host system, but
rather by inheriting fewer.  Everything that we inherit from the host
system is a potential impurity, and this would add more of them.

We should not inherit /dev from the host system at all, but rather
create it from scratch with just the things we need.  IMO, that's the
only truly proper solution.

Thoughts?

    Mark

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/shm inconsistency in chroot
  2014-01-23 19:56 ` Mark H Weaver
@ 2014-01-24 10:16   ` Sree Harsha Totakura
  2014-01-24 14:12     ` Shea Levy
  0 siblings, 1 reply; 10+ messages in thread
From: Sree Harsha Totakura @ 2014-01-24 10:16 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, nix-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 01/23/2014 08:56 PM, Mark H Weaver wrote:
> We should not inherit /dev from the host system at all, but rather 
> create it from scratch with just the things we need.  IMO, that's
> the only truly proper solution.

We can try creating a fixed set of device nodes, for example:
/dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
this before?

Sree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlLiPZUACgkQO2+K8UPCHzvyuwCgpPH4ndRBqFkITqbPcQ1UN4Ws
JsYAniMrgj8mBvNMC7Jq1AkFv+bV/VUj
=DbCU
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/shm inconsistency in chroot
  2014-01-24 10:16   ` Sree Harsha Totakura
@ 2014-01-24 14:12     ` Shea Levy
  2014-01-24 17:08       ` [Nix-dev] " Ludovic Courtès
  2014-01-24 17:13       ` Mark H Weaver
  0 siblings, 2 replies; 10+ messages in thread
From: Shea Levy @ 2014-01-24 14:12 UTC (permalink / raw)
  To: sreeharsha; +Cc: guix-devel, Mark H Weaver, nix-dev

On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 01/23/2014 08:56 PM, Mark H Weaver wrote:
>> We should not inherit /dev from the host system at all, but rather
>> create it from scratch with just the things we need.  IMO, that's
>> the only truly proper solution.
> We can try creating a fixed set of device nodes, for example:
> /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
> this before?

Another option is to mount  a devtmpfs there, for systems which support it.

> Sree
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iEYEARECAAYFAlLiPZUACgkQO2+K8UPCHzvyuwCgpPH4ndRBqFkITqbPcQ1UN4Ws
> JsYAniMrgj8mBvNMC7Jq1AkFv+bV/VUj
> =DbCU
> -----END PGP SIGNATURE-----
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Nix-dev] /dev/shm inconsistency in chroot
  2014-01-24 14:12     ` Shea Levy
@ 2014-01-24 17:08       ` Ludovic Courtès
  2014-01-24 17:13       ` Mark H Weaver
  1 sibling, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2014-01-24 17:08 UTC (permalink / raw)
  To: Shea Levy; +Cc: guix-devel, nix-dev

Shea Levy <shea@shealevy.com> skribis:

> On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On 01/23/2014 08:56 PM, Mark H Weaver wrote:
>>> We should not inherit /dev from the host system at all, but rather
>>> create it from scratch with just the things we need.  IMO, that's
>>> the only truly proper solution.
>> We can try creating a fixed set of device nodes, for example:
>> /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
>> this before?
>
> Another option is to mount  a devtmpfs there, for systems which support it.

Both options look good to me.  Using devtmpfs would be easier, but I
don’t see any documentation for it.  Are its contents really
deterministic?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Nix-dev] /dev/shm inconsistency in chroot
  2014-01-24 14:12     ` Shea Levy
  2014-01-24 17:08       ` [Nix-dev] " Ludovic Courtès
@ 2014-01-24 17:13       ` Mark H Weaver
  2014-01-24 17:44         ` Sree Harsha Totakura
  2014-03-21  9:01         ` [Nix-dev] " Ludovic Courtès
  1 sibling, 2 replies; 10+ messages in thread
From: Mark H Weaver @ 2014-01-24 17:13 UTC (permalink / raw)
  To: Shea Levy; +Cc: guix-devel, nix-dev

Shea Levy <shea@shealevy.com> writes:

> On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On 01/23/2014 08:56 PM, Mark H Weaver wrote:
>>> We should not inherit /dev from the host system at all, but rather
>>> create it from scratch with just the things we need.  IMO, that's
>>> the only truly proper solution.
>> We can try creating a fixed set of device nodes, for example:
>> /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
>> this before?
>
> Another option is to mount  a devtmpfs there, for systems which support it.

The thing is, we don't actually want most of the system's devices to be
in the build environment, do we?  These are all impurities.  I don't
think we want /dev/sda, for example.

     Mark

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/shm inconsistency in chroot
  2014-01-24 17:13       ` Mark H Weaver
@ 2014-01-24 17:44         ` Sree Harsha Totakura
  2014-01-24 21:17           ` [Nix-dev] " Ludovic Courtès
  2014-03-21  9:01         ` [Nix-dev] " Ludovic Courtès
  1 sibling, 1 reply; 10+ messages in thread
From: Sree Harsha Totakura @ 2014-01-24 17:44 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, nix-dev



On 01/24/2014 06:13 PM, Mark H Weaver wrote:
> Shea Levy <shea@shealevy.com> writes:
>> > Another option is to mount  a devtmpfs there, for systems which support it.

devtmpfs may give different devices on each machine and they may hinder
our build reproducibility.

> The thing is, we don't actually want most of the system's devices to be
> in the build environment, do we?  These are all impurities.  I don't
> think we want /dev/sda, for example.

Sure, I agree.  I propose we start enumerating commonly needed devices
and create them.  If in future, a package requires access to certain
device while building (or during tests) we can include it in our list of
created device nodes.

Sree

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Nix-dev] /dev/shm inconsistency in chroot
  2014-01-24 17:44         ` Sree Harsha Totakura
@ 2014-01-24 21:17           ` Ludovic Courtès
  2014-01-24 21:45             ` Shea Levy
  0 siblings, 1 reply; 10+ messages in thread
From: Ludovic Courtès @ 2014-01-24 21:17 UTC (permalink / raw)
  To: Sree Harsha Totakura; +Cc: Shea Levy, nix-dev, guix-devel

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> On 01/24/2014 06:13 PM, Mark H Weaver wrote:
>> Shea Levy <shea@shealevy.com> writes:
>>> > Another option is to mount  a devtmpfs there, for systems which support it.
>
> devtmpfs may give different devices on each machine and they may hinder
> our build reproducibility.

OK.

>> The thing is, we don't actually want most of the system's devices to be
>> in the build environment, do we?  These are all impurities.  I don't
>> think we want /dev/sda, for example.
>
> Sure, I agree.  I propose we start enumerating commonly needed devices
> and create them.

Sounds good.

The major/minor device numbers may not be portable across OSes, which
may be a problem for Nix, so that code may need to be #ifdef’d.

> If in future, a package requires access to certain device while
> building (or during tests) we can include it in our list of created
> device nodes.

Yes, but keep in mind that we’re not going to change that often, because
it’s inconvenient.

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/shm inconsistency in chroot
  2014-01-24 21:17           ` [Nix-dev] " Ludovic Courtès
@ 2014-01-24 21:45             ` Shea Levy
  0 siblings, 0 replies; 10+ messages in thread
From: Shea Levy @ 2014-01-24 21:45 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Mark H Weaver, nix-dev

On 01/24/2014 04:17 PM, Ludovic Courtès wrote:
> Sree Harsha Totakura <sreeharsha@totakura.in> skribis:
>
>> On 01/24/2014 06:13 PM, Mark H Weaver wrote:
>>> Shea Levy <shea@shealevy.com> writes:
>>>>> Another option is to mount  a devtmpfs there, for systems which support it.
>> devtmpfs may give different devices on each machine and they may hinder
>> our build reproducibility.
> OK.
>
>>> The thing is, we don't actually want most of the system's devices to be
>>> in the build environment, do we?  These are all impurities.  I don't
>>> think we want /dev/sda, for example.
>> Sure, I agree.  I propose we start enumerating commonly needed devices
>> and create them.
> Sounds good.
>
> The major/minor device numbers may not be portable across OSes, which
> may be a problem for Nix, so that code may need to be #ifdef’d.

Generally a good idea, but note that for now chroot is not enabled on 
non-Linux

>> If in future, a package requires access to certain device while
>> building (or during tests) we can include it in our list of created
>> device nodes.
> Yes, but keep in mind that we’re not going to change that often, because
> it’s inconvenient.
>
> Thanks,
> Ludo’.

_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Nix-dev] /dev/shm inconsistency in chroot
  2014-01-24 17:13       ` Mark H Weaver
  2014-01-24 17:44         ` Sree Harsha Totakura
@ 2014-03-21  9:01         ` Ludovic Courtès
  1 sibling, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2014-03-21  9:01 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

Mark H Weaver <mhw@netris.org> skribis:

> Shea Levy <shea@shealevy.com> writes:
>
>> On 01/24/2014 05:16 AM, Sree Harsha Totakura wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> On 01/23/2014 08:56 PM, Mark H Weaver wrote:
>>>> We should not inherit /dev from the host system at all, but rather
>>>> create it from scratch with just the things we need.  IMO, that's
>>>> the only truly proper solution.
>>> We can try creating a fixed set of device nodes, for example:
>>> /dev/null, /dev/random, /dev/urandom, /dev/sda etc.  Has anyone tried
>>> this before?
>>
>> Another option is to mount  a devtmpfs there, for systems which support it.
>
> The thing is, we don't actually want most of the system's devices to be
> in the build environment, do we?  These are all impurities.  I don't
> think we want /dev/sda, for example.

For the record, with
<https://github.com/NixOS/nix/commit/3fd01b171a74d28dc8e48b9ee5f2d0e9a3915fb8>,
the daemon creates /dev deterministically.  (This change landed in
guix-daemon with the latest ‘nix-upstream’ update.)

Ludo’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2014-03-21  9:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-23 19:21 /dev/shm inconsistency in chroot Sree Harsha Totakura
2014-01-23 19:56 ` Mark H Weaver
2014-01-24 10:16   ` Sree Harsha Totakura
2014-01-24 14:12     ` Shea Levy
2014-01-24 17:08       ` [Nix-dev] " Ludovic Courtès
2014-01-24 17:13       ` Mark H Weaver
2014-01-24 17:44         ` Sree Harsha Totakura
2014-01-24 21:17           ` [Nix-dev] " Ludovic Courtès
2014-01-24 21:45             ` Shea Levy
2014-03-21  9:01         ` [Nix-dev] " Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).