Running IceCat in a container

Running IceCat in a container

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

Hello, everyone:

I'm running IceCat in a container, with the goal of isolating it form
the rest of my system as much as possible without running a full
VM.  Here's what I have so far:

#+BEGIN_SRC sh
guix environment \
     --container \
     --network \
     -r "$gc_root" \
     --share=/tmp/.X11-unix/ \
     --expose=/etc/machine-id \
     --share=$HOME/.mozilla/ \
     --share=$HOME/.cache/mozilla/ \
     --share=$HOME/.Xauthority \
     --share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \
     --ad-hoc icecat coreutils
     -- \
     env DISPLAY="$DISPLAY" icecat "$@"
#+END_SRC

The most difficult problem I'm having is dealing with
fonts.  Specifically, I want to share the system fonts
(/run/current-system/profile/share/fonts).  The problem is, I can't just
expose that directory, because it symlinks into the store, and those
derivations don't exist within the container.

  - I do not want to expose all of /gnu.
  - I can provide the fonts as inputs to the environment, but I do not
    want to have to run fc-cache every time I start the container,
    because that is very slow.  Exposing the cache directory doesn't
    help since the derivation used in the container ($GUIX_ENVIRONMENT)
    always appears to be different than the font derivation used on my
    system, and also by my user.
  - I don't want to expose my user's entire ~/.guix-profile/.

I'm making things difficult for myself because I want as little
shared/exposed with the container as possible.

To complicate things further, for privacy, I don't want my user exposed
to the container via the name of my home directory; Guix creates that
automatically.  I haven't yet looked at the code to see what exactly it
does.

Is there a reasonable solution here?  Should I create a separate user
entirely and then just share the entire home directory?  I'm not sure
how that might impact X11 socket sharing, though.  Can I maybe
pre-create an image, already having run fc-cache, and run that image as
a container (like one would with Docker?)?  But that wouldn't solve my
user privacy issue.

Thanks,

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[Ludovic Courtès]

Hi Mike,

Mike Gerwitz <mtg@gnu.org> skribis:

> I'm running IceCat in a container, with the goal of isolating it form
> the rest of my system as much as possible without running a full
> VM.  Here's what I have so far:
>
> #+BEGIN_SRC sh
> guix environment \
>      --container \
>      --network \
>      -r "$gc_root" \
>      --share=/tmp/.X11-unix/ \
>      --expose=/etc/machine-id \
>      --share=$HOME/.mozilla/ \
>      --share=$HOME/.cache/mozilla/ \
>      --share=$HOME/.Xauthority \
>      --share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \
>      --ad-hoc icecat coreutils
>      -- \
>      env DISPLAY="$DISPLAY" icecat "$@"
> #+END_SRC

I’ve been dreaming of having it baked in into the shell (like Plash did;
we could write a Bash or Guile-Bash extension) or something along these
lines…

> The most difficult problem I'm having is dealing with
> fonts.  Specifically, I want to share the system fonts
> (/run/current-system/profile/share/fonts).  The problem is, I can't just
> expose that directory, because it symlinks into the store, and those
> derivations don't exist within the container.
>
>   - I do not want to expose all of /gnu.
>   - I can provide the fonts as inputs to the environment, but I do not
>     want to have to run fc-cache every time I start the container,
>     because that is very slow.  Exposing the cache directory doesn't
>     help since the derivation used in the container ($GUIX_ENVIRONMENT)
>     always appears to be different than the font derivation used on my
>     system, and also by my user.
>   - I don't want to expose my user's entire ~/.guix-profile/.
>
> I'm making things difficult for myself because I want as little
> shared/exposed with the container as possible.
>
> To complicate things further, for privacy, I don't want my user exposed
> to the container via the name of my home directory; Guix creates that
> automatically.  I haven't yet looked at the code to see what exactly it
> does.

“guix environment -C” makes $PWD shared; if you do (cd /tmp; guix
environment -C …), then /tmp is shared but not $HOME.

> Is there a reasonable solution here?  Should I create a separate user
> entirely and then just share the entire home directory?  I'm not sure
> how that might impact X11 socket sharing, though.  Can I maybe
> pre-create an image, already having run fc-cache, and run that image as
> a container (like one would with Docker?)?  But that wouldn't solve my
> user privacy issue.

Perhaps you could define a package that simply runs “fc-cache” with the
fonts it has as inputs, and then pass that to ‘guix environment’.

But really, we should make a specific tool for this.

Thoughts?

Ludo’.

Re: Running IceCat in a container

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]

On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote:
> “guix environment -C” makes $PWD shared; if you do (cd /tmp; guix
> environment -C …), then /tmp is shared but not $HOME.

I am doing that (I made a ~/.empty so as not to expose /tmp contents),
but that still creates the home dir (as documented):

  $ pwd && guix environment -C coreutils -- ls /home
  /tmp
  mikegerwitz

>> Is there a reasonable solution here?  Should I create a separate user
>> entirely and then just share the entire home directory?  I'm not sure
>> how that might impact X11 socket sharing, though.  Can I maybe
>> pre-create an image, already having run fc-cache, and run that image as
>> a container (like one would with Docker?)?  But that wouldn't solve my
>> user privacy issue.
>
> Perhaps you could define a package that simply runs “fc-cache” with the
> fonts it has as inputs, and then pass that to ‘guix environment’.

Oh, interesting; I wouldn't have thought of that.  If there is a general
solution/script, I think this needs to be considered---automatically
including system fonts; any program that displays text needs a broad
range of UTF-8/multi-lingual font support.  If I were to containerize my
shell, I'd have the same problem.

> But really, we should make a specific tool for this.
>
> Thoughts?

Yes, though I'd be curious how you'd approach it---each package requires
certain paths be shared, and those paths would further depend on user
privacy preferences, so need to be able to be overridden.  Perhaps it'd
be useful for those paths to be part of a package definition---the paths
that a program creates/uses at runtime, and perhaps additional metadata
associated with them, such as whether the path is necessary for its
operation (will it break the program if it's ephemeral or
read-only?).  Something extensible for the future.

Those directory metadata may have other uses that may make it worth
adding, but I haven't given it much thought.  For example, if a user
wishes to purge a package from her system, she could opt to purge those
paths from her home directory.  Or maybe Guix could create a backup of
user preferences such that a restoration would involve only a list of
packages and a tarball of those directories.  Might be useful for
provisioning as well.

Just some thoughts.  I'm too new to Guix to provide much.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

On Tue, Jan 16, 2018 at 21:25:19 -0500, Mike Gerwitz wrote:
> On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote:
>> Perhaps you could define a package that simply runs “fc-cache” with the
>> fonts it has as inputs, and then pass that to ‘guix environment’.
>
> Oh, interesting; I wouldn't have thought of that.

Actually, I could use a little bit of help.

After hours of fontconf research and related stuff (more than I ever
cared to know), I think I'll be able to get away with running fc-cache
as you suggested using a package.

My ultimate goal I think is to still use the user's fonts, but I still
don't know a way to do that, since the /gnu symlinks are unavailable
within the container.[0] It _does_ work if the links are identical
between the host and cointainer---e.g. copying the font files into
~/.local/share/fonts, but that's obviously undesirable.

Unless you happen to know a good way to selectively expose those to a
container.

With that said, I'm having trouble creating a package: it wants a
`source' field, but this is a metapackage of sorts, and I didn't intend
on having any source files; I can generate them using the builder and
trivial-build-system.  How can I work around this?

Thanks.


[0]: What seems to be the case---which is probably obvious to anyone who
knows about this stuff---is that X11 on the host (since we're sharing
the socket) needs access to the font in addition to the software running
in the container.  I don't think this is the case for traditional X11
fonts (not using fontconf), but I'm not dealing with those.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Wed, Jan 17, 2018 at 02:05:28PM -0500, Mike Gerwitz wrote:
> With that said, I'm having trouble creating a package: it wants a
> `source' field, but this is a metapackage of sorts, and I didn't intend
> on having any source files; I can generate them using the builder and
> trivial-build-system.  How can I work around this?

You can use (source #f) with the trivial build system for metapackages.

Check out the package definitions of 'gnome' and
'gnome-default-applications' in gnu/packages/gnome.scm for some
examples.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Running IceCat in a container

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Wed, Jan 17, 2018 at 15:20:44 -0800, Leo Famulari wrote:
> You can use (source #f) with the trivial build system for metapackages.
>
> Check out the package definitions of 'gnome' and
> 'gnome-default-applications' in gnu/packages/gnome.scm for some
> examples.

Ah, great, thank you!  I tried looking for examples, but it looks like I
never expected #f and inadvertently filtered the line out of my grep
results.  Those will be very helpful.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[Ludovic Courtès]

Mike Gerwitz <mtg@gnu.org> skribis:

> On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote:

[...]

>> But really, we should make a specific tool for this.
>>
>> Thoughts?
>
> Yes, though I'd be curious how you'd approach it---each package requires
> certain paths be shared, and those paths would further depend on user
> privacy preferences, so need to be able to be overridden.

For a start, we could simply share everything that’s in:

  guix gc -R $(guix build the-package)

plus /tmp/.X11-unix, maybe $PWD, and a few more.

After that we could add the option to let users define what needs to be
shared (like the ‘file-system-mapping’ API we already have).  We could
have a predefined settings for X11 and console apps to minimize
boilerplate.  And like you write, the settings could be added as package
metadata.

Plash (Mark Seaborn’s POLA shell which used to live at
<http://plash.beasts.org/>) would automatically determine what needs to
be mapped based on the command line.  For instance, if you typed:

  gcc -o foo.o ~/src/bar/foo.c

then it would map ~/src/bar/foo.c as read-only and $(dirname foo.o) as
read-write.

Food for thought!

Ludo’.

Re: Running IceCat in a container

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

ludo@gnu.org (Ludovic Courtès) skribis:

> Mike Gerwitz <mtg@gnu.org> skribis:
>
>> On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote:
>
> [...]
>
>>> But really, we should make a specific tool for this.
>>>
>>> Thoughts?
>>
>> Yes, though I'd be curious how you'd approach it---each package requires
>> certain paths be shared, and those paths would further depend on user
>> privacy preferences, so need to be able to be overridden.
>
> For a start, we could simply share everything that’s in:
>
>   guix gc -R $(guix build the-package)
>
> plus /tmp/.X11-unix, maybe $PWD, and a few more.

If you drop the attached file under guix/scripts/, you can then run:

  guix run icecat icecat

and similar.  This particular example doesn’t work well because of the
font issue you’re familiar with, but you get the idea.  :-)

Ludo’.


[-- Attachment #2: The 'guix run' command. --]
[-- Type: text/x-scheme, Size: 4288 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Ludovic Courtès <ludo@gnu.org>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (guix scripts run)
  #:use-module (guix ui)
  #:use-module (guix scripts)
  #:use-module (guix store)
  #:use-module (guix packages)
  #:use-module (guix derivations)
  #:use-module ((guix build utils) #:select (which mkdir-p))
  #:use-module (gnu build linux-container)
  #:use-module (gnu system file-systems)
  #:use-module (gnu packages)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-11)
  #:use-module (srfi srfi-37)
  #:use-module (ice-9 match)
  #:export (guix-run))

(define %options
  (list (option '(#\h "help") #f #f
                (lambda args
                  (show-help)
                  (exit 0)))
        (option '(#\V "version") #f #f
                (lambda args
                  (show-version-and-exit "guix run")))))

(define (show-help)
  (display (G_ "Usage: guix run PACKAGE COMMAND...
Run COMMAND from PACKAGE in a container.\n"))
  (newline)
  (display (G_ "
  -h, --help             display this help and exit"))
  (display (G_ "
  -V, --version          display version information and exit"))
  (newline)
  (show-bug-report-information))

\f

(define (bind-mount-spec/ro item)
  (and (file-exists? item)
       (file-system
         (device item)
         (mount-point item)
         (title 'device)
         (type "none")
         (flags '(bind-mount read-only))
         (check? #f))))

(define (bind-mount-spec/rw item)
  (and (file-exists? item)
       (file-system
         (inherit (bind-mount-spec/ro item))
         (flags '(bind-mount)))))

(define %writable-things
  (list "/var/run/nscd/socket"
        (string-append (getenv "HOME") "/.Xauthority")
        "/tmp/.X11-unix"
        "/etc/machine-id"))

(define (guix-run . args)
  (with-error-handling
    (match (reverse (parse-command-line args %options '(())
                                        #:argument-handler cons))
      ((spec command args ...)
       (with-store store
         (let-values (((package output)
                       (specification->package+output spec)))
           (let* ((drv    (package-derivation store package))
                  (prefix (derivation->output-path drv output)))
             (show-what-to-build store (list drv))
             (build-derivations store (list drv))

             (let* ((items (requisites store (list prefix)))
                    (env   (environ))
                    (full  (search-path (list (string-append prefix "/bin")
                                              (string-append prefix "/sbin"))
                                        command)))
               (unless full
                 (leave (G_ "command '~a' not found in package '~a'~%")
                        command (package-name package)))

               (call-with-container
                   (append (filter-map bind-mount-spec/ro items)
                           (filter-map bind-mount-spec/rw %writable-things))
                 (lambda ()
                   (environ env)                  ;TODO: filter ENV
                   (mkdir-p (getenv "HOME"))

                   (newline)
                   (catch #t
                     (lambda ()
                       (apply execl full command args))
                     (lambda (key . args)
                       (print-exception (current-error-port) #f key args)
                       (exit 1))))
                 #:namespaces (delq 'net %namespaces))))))))))

[bug#30254] [PATCH 0/3] guix environment --user, --link-profile, --no-cwd

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

On help-guix I initiated a conversation on using IceCat within a container
(<87vag2wopo.fsf@gnu.org>).  This covers some of the lower-level concepts I
was thinking off.  Specifically:

0. The ability to hide the user (and home directory) from procsses within the
   container.  This includes rewritting mapped paths;
1. Suppressing the behavior of automatically sharing cwd; and
2. Linking $GUIX_ENVIRONMENT to ~/.guix-profile.

The first two are for privacy (#1 is for conveinence, since creating an empty
dir just to cd into it is a bit klugy as a workaround).  #2 was motivated by
my needs with font-config, but I can imaging that it'd be useful elsewhere
as well.  It only really makes sense if you're not sharing your home
directory.

Mike Gerwitz (3):
  scripts: environment: Add --link-profile.
  scripts: environment: Add --user.
  scripts: environment: Add --no-cwd.

 doc/guix.texi                |  59 +++++++++++++-
 guix/scripts/environment.scm | 178 +++++++++++++++++++++++++++++++++++--------
 tests/guix-environment.sh    |  30 ++++++++
 3 files changed, 233 insertions(+), 34 deletions(-)

-- 
2.15.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30255] [PATCH 1/3] scripts: environment: Add --link-profile.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 9525 bytes --]

This change is motivated by attempts to run programs (like GNU IceCat) within
containers.  The 'fontconfig' program, for example, is configured explicitly
to check ~/.guix-profile for additional fonts.

There were no existing container tests in 'tests/guix-environment.sh', but I
added one anyway for this change.

* doc/guix.texi (Invoking guix environment): Add '--link-profile'.
* guix/scripts/environment.scm (show-help): Add '--link-profile'.
(%options): Add 'link-profile' as '#\P', assigned to 'link-profile?'.
(lnk-environment): New procedure.
(launch-environment/container): Use it when 'link-profile?'.
[link-profile?]: New parameter.
(guix-environment): Leave when '--link-prof' but not '--container'.  Add
'#:link-profile?' argument to 'launch-environment/container' application.
* tests/guix-environment.sh: New '--link-profile' test.
---
 doc/guix.texi                | 17 +++++++++++++++++
 guix/scripts/environment.scm | 43 +++++++++++++++++++++++++++++++++++++------
 tests/guix-environment.sh    | 12 ++++++++++++
 3 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1ecdcd218..3b6ae1ab9 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -46,6 +46,7 @@ Copyright @copyright{} 2017 Andy Wingo@*
 Copyright @copyright{} 2017 Arun Isaac@*
 Copyright @copyright{} 2017 nee@*
 Copyright @copyright{} 2018 Rutger Helling
+Copyright @copyright{} 2018 Mike Gerwitz
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -7166,6 +7167,22 @@ For containers, share the network namespace with the host system.
 Containers created without this flag only have access to the loopback
 device.
 
+@item --link-profile
+@itemx -P
+For containers, link the environment profile to
+@file{~/.guix-profile} within the container.  This is equivalent to
+running the command @command{ln -s $GUIX_ENVIRONMENT ~/.guix-profile}
+within the container.  Linking will fail and abort the environment if
+the directory already exists, which will certainly be the case if
+@command{guix environment} was invoked in the user's home directory.
+
+Certain packages are configured to look in
+@code{~/.guix-profile} for configuration files and data;@footnote{For
+example, the @code{fontconfig} package inspects
+@file{~/.guix-profile/share/fonts} for additional fonts.}
+@code{--link-profile} allows these programs to behave as expected within
+the environment.
+
 @item --expose=@var{source}[=@var{target}]
 For containers, expose the file system @var{source} from the host system
 as the read-only file system @var{target} within the container.  If
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index d2568e6a7..771574c15 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015 David Thompson <davet@gnu.org>
 ;;; Copyright © 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2018 Mike Gerwitz <mtg@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -157,6 +158,9 @@ COMMAND or an interactive shell in that environment.\n"))
   -C, --container        run command within an isolated container"))
   (display (G_ "
   -N, --network          allow containers to access the network"))
+  (display (G_ "
+  -P, --link-profile     link environment profile to ~/.guix-profile within
+                         an isolated container"))
   (display (G_ "
       --share=SPEC       for containers, share writable host file system
                          according to SPEC"))
@@ -236,6 +240,9 @@ COMMAND or an interactive shell in that environment.\n"))
          (option '(#\N "network") #f #f
                  (lambda (opt name arg result)
                    (alist-cons 'network? #t result)))
+         (option '(#\P "link-profile") #f #f
+                 (lambda (opt name arg result)
+                   (alist-cons 'link-profile? #t result)))
          (option '("share") #t #f
                  (lambda (opt name arg result)
                    (alist-cons 'file-system-mapping
@@ -384,18 +391,20 @@ environment variables are cleared before setting the new ones."
            ((_ . status) status)))))
 
 (define* (launch-environment/container #:key command bash user-mappings
-                                       profile paths network?)
+                                       profile paths link-profile? network?)
   "Run COMMAND within a container that features the software in PROFILE.
 Environment variables are set according to PATHS, a list of native search
 paths.  The global shell is BASH, a file name for a GNU Bash binary in the
 store.  When NETWORK?, access to the host system network is permitted.
 USER-MAPPINGS, a list of file system mappings, contains the user-specified
-host file systems to mount inside the container."
+host file systems to mount inside the container.  LINK-PROFILE? creates a
+symbolic link from ~/.guix-profile to the environment profile."
   (mlet %store-monad ((reqs (inputs->requisites
                              (list (direct-store-path bash) profile))))
     (return
-     (let* ((cwd (getcwd))
-            (passwd (getpwuid (getuid)))
+     (let* ((cwd      (getcwd))
+            (passwd   (getpwuid (getuid)))
+            (home-dir (passwd:dir passwd))
             ;; Bind-mount all requisite store items, user-specified mappings,
             ;; /bin/sh, the current working directory, and possibly networking
             ;; configuration files within the container.
@@ -440,8 +449,13 @@ host file systems to mount inside the container."
 
             ;; Create a dummy home directory under the same name as on the
             ;; host.
-            (mkdir-p (passwd:dir passwd))
-            (setenv "HOME" (passwd:dir passwd))
+            (mkdir-p home-dir)
+            (setenv "HOME" home-dir)
+
+            ;; If requested, link $GUIX_ENVIRONMENT to $HOME/.guix-profile;
+            ;; this allows programs expecting that path to continue working as
+            ;; expected within a container.
+            (when link-profile? (link-environment profile home-dir))
 
             ;; Create a dummy /etc/passwd to satisfy applications that demand
             ;; to read it, such as 'git clone' over SSH, a valid use-case when
@@ -471,6 +485,18 @@ host file systems to mount inside the container."
                            (delq 'net %namespaces) ; share host network
                            %namespaces)))))))
 
+(define (link-environment profile home-dir)
+  "Create a symbolic link from HOME-DIR/.guix-profile to PROFILE."
+  (let ((profile-dir (string-append home-dir "/.guix-profile")))
+    (catch 'system-error
+      (lambda ()
+        (symlink profile profile-dir))
+      (lambda args
+        (if (= EEXIST (system-error-errno args))
+            (leave (G_ "cannot link profile: path '~a' already exists within container~%")
+                   profile-dir)
+            (apply throw args))))))
+
 (define (environment-bash container? bootstrap? system)
   "Return a monadic value in the store monad for the version of GNU Bash
 needed in the environment for SYSTEM, if any.  If CONTAINER? is #f, return #f.
@@ -544,6 +570,7 @@ message if any test fails."
     (let* ((opts       (parse-args args))
            (pure?      (assoc-ref opts 'pure))
            (container? (assoc-ref opts 'container?))
+           (link-prof? (assoc-ref opts 'link-profile?))
            (network?   (assoc-ref opts 'network?))
            (bootstrap? (assoc-ref opts 'bootstrap?))
            (system     (assoc-ref opts 'system))
@@ -577,6 +604,9 @@ message if any test fails."
 
       (when container? (assert-container-features))
 
+      (when (and (not container?) link-prof?)
+        (leave (G_ "--link-prof cannot be used without --container~%")))
+
       (with-store store
         (set-build-options-from-command-line store opts)
 
@@ -626,6 +656,7 @@ message if any test fails."
                                                   #:user-mappings mappings
                                                   #:profile profile
                                                   #:paths paths
+                                                  #:link-profile? link-prof?
                                                   #:network? network?)))
                  (else
                   (return
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index bf5ca17fa..e995636df 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -62,6 +62,18 @@ fi
 guix environment --bootstrap --ad-hoc guile-bootstrap --pure \
      -- "$SHELL" -c 'test -f "$GUIX_ENVIRONMENT/bin/guile"'
 
+# Make sure 'GUIX_ENVIRONMENT' is linked to '~/.guix-profile' when requested
+# within a container
+(
+  linktest='(exit (string=? (getenv "GUIX_ENVIRONMENT")
+(readlink (string-append (getenv "HOME") "/.guix-profile"))))'
+
+  cd "$tmpdir" \
+     && guix environment --bootstrap --container --link-profile \
+             --ad-hoc guile-bootstrap --pure \
+             -- guile -c "$linktest"
+)
+
 # Make sure '-r' works as expected.
 rm -f "$gcroot"
 expected="`guix environment --bootstrap --ad-hoc guile-bootstrap \
-- 
2.15.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30257] [PATCH 2/3] scripts: environment: Add --user.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 14422 bytes --]

This change allows overriding the home directory of all filesystem mappings to
help hide the identity of the calling user in a container.

* doc/guix.texi (Invoking guix environment)[--container]: Mention --user.
[--user]: Add item.
* guix/scripts/environment.scm (show-help): Add --user.
(%options): Add --user.
(launch-environment/container) Add 'user' parameter.  Update doc.  Override
'user-mappings' using 'override-user-mappings'.  Consider override for chdir.
(mock-passwd, user-override-home, overrid-euser-dir): New procedures.
(guix-environment): Disallow --user without --container.  Provide user to
'launch-environment/container'.
* tests/guix-environment.sh: Add user test.
---
 doc/guix.texi                |  34 ++++++++++--
 guix/scripts/environment.scm | 122 ++++++++++++++++++++++++++++++++++---------
 tests/guix-environment.sh    |  10 ++++
 3 files changed, 137 insertions(+), 29 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 3b6ae1ab9..8218c6637 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -7156,10 +7156,11 @@ Attempt to build for @var{system}---e.g., @code{i686-linux}.
 @cindex container
 Run @var{command} within an isolated container.  The current working
 directory outside the container is mapped inside the container.
-Additionally, a dummy home directory is created that matches the current
-user's home directory, and @file{/etc/passwd} is configured accordingly.
-The spawned process runs as the current user outside the container, but
-has root privileges in the context of the container.
+Additionally, unless overridden with @code{--user}, a dummy home
+directory is created that matches the current user's home directory, and
+@file{/etc/passwd} is configured accordingly.  The spawned process runs
+as the current user outside the container, but has root privileges in
+the context of the container.
 
 @item --network
 @itemx -N
@@ -7183,6 +7184,31 @@ example, the @code{fontconfig} package inspects
 @code{--link-profile} allows these programs to behave as expected within
 the environment.
 
+@item --user=@var{user}
+@itemx -u @var{user}
+For containers, use the username @var{user} in place of the current
+user.  The generated @file{/etc/passwd} entry within the container will
+contain the name @var{user}; the home directory will be
+@file{/home/USER}; and no user GECOS data will be copied.  @var{user}
+need not exist on the system.
+
+Additionally, any shared or exposed path (see @code{--share} and
+@code{--expose} respectively) whose target is within the current user's
+home directory will be remapped relative to @file{/home/USER}; this
+includes the automatic mapping of the current working directory.
+
+@example
+# will expose paths as /home/foo/wd, /home/foo/test, and /home/foo/target
+cd $HOME/wd
+guix environment --container --user=foo \
+     --expose=$HOME/test \
+     --expose=/tmp/target=$HOME/target
+@end example
+
+While this will limit the leaking of user identity through home paths
+and each of the user fields, this is only one useful component of a
+broader privacy/anonymity solution---not one in and of itself.
+
 @item --expose=@var{source}[=@var{target}]
 For containers, expose the file system @var{source} from the host system
 as the read-only file system @var{target} within the container.  If
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 771574c15..f50018faf 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -161,6 +161,10 @@ COMMAND or an interactive shell in that environment.\n"))
   (display (G_ "
   -P, --link-profile     link environment profile to ~/.guix-profile within
                          an isolated container"))
+  (display (G_ "
+  -u, --user=USER        instead of copying the name and home of the current
+                         user into an isolated container, use the name USER
+                         with home directory /home/USER"))
   (display (G_ "
       --share=SPEC       for containers, share writable host file system
                          according to SPEC"))
@@ -243,6 +247,10 @@ COMMAND or an interactive shell in that environment.\n"))
          (option '(#\P "link-profile") #f #f
                  (lambda (opt name arg result)
                    (alist-cons 'link-profile? #t result)))
+         (option '(#\u "user") #t #f
+                 (lambda (opt name arg result)
+                   (alist-cons 'user arg
+                               (alist-delete 'user result eq?))))
          (option '("share") #t #f
                  (lambda (opt name arg result)
                    (alist-cons 'file-system-mapping
@@ -390,43 +398,50 @@ environment variables are cleared before setting the new ones."
     (pid (match (waitpid pid)
            ((_ . status) status)))))
 
-(define* (launch-environment/container #:key command bash user-mappings
+(define* (launch-environment/container #:key command bash user user-mappings
                                        profile paths link-profile? network?)
   "Run COMMAND within a container that features the software in PROFILE.
 Environment variables are set according to PATHS, a list of native search
 paths.  The global shell is BASH, a file name for a GNU Bash binary in the
 store.  When NETWORK?, access to the host system network is permitted.
 USER-MAPPINGS, a list of file system mappings, contains the user-specified
-host file systems to mount inside the container.  LINK-PROFILE? creates a
-symbolic link from ~/.guix-profile to the environment profile."
+host file systems to mount inside the container.  If USER is not #f, each
+target of USER-MAPPINGS will be re-written relative to '/home/USER', and USER
+will be used for the passwd entry.  LINK-PROFILE? creates a symbolic link from
+~/.guix-profile to the environment profile."
   (mlet %store-monad ((reqs (inputs->requisites
                              (list (direct-store-path bash) profile))))
     (return
      (let* ((cwd      (getcwd))
-            (passwd   (getpwuid (getuid)))
+            (home     (getenv "HOME"))
+            (passwd   (mock-passwd (getpwuid (getuid))
+                                   user
+                                   bash))
             (home-dir (passwd:dir passwd))
             ;; Bind-mount all requisite store items, user-specified mappings,
             ;; /bin/sh, the current working directory, and possibly networking
             ;; configuration files within the container.
             (mappings
-             (append user-mappings
-                     ;; Current working directory.
-                     (list (file-system-mapping
-                            (source cwd)
-                            (target cwd)
-                            (writable? #t)))
-                     ;; When in Rome, do as Nix build.cc does: Automagically
-                     ;; map common network configuration files.
-                     (if network?
-                         %network-file-mappings
-                         '())
-                     ;; Mappings for the union closure of all inputs.
-                     (map (lambda (dir)
-                            (file-system-mapping
-                             (source dir)
-                             (target dir)
-                             (writable? #f)))
-                          reqs)))
+             (override-user-mappings
+              user home
+              (append user-mappings
+                      ;; Current working directory.
+                      (list (file-system-mapping
+                             (source cwd)
+                             (target cwd)
+                             (writable? #t)))
+                      ;; When in Rome, do as Nix build.cc does: Automagically
+                      ;; map common network configuration files.
+                      (if network?
+                          %network-file-mappings
+                          '())
+                      ;; Mappings for the union closure of all inputs.
+                      (map (lambda (dir)
+                             (file-system-mapping
+                              (source dir)
+                              (target dir)
+                              (writable? #f)))
+                           reqs))))
             (file-systems (append %container-file-systems
                                   (map file-system-mapping->bind-mount
                                        mappings))))
@@ -447,8 +462,7 @@ symbolic link from ~/.guix-profile to the environment profile."
                       ;; The same variables as in Nix's 'build.cc'.
                       '("TMPDIR" "TEMPDIR" "TMP" "TEMP"))
 
-            ;; Create a dummy home directory under the same name as on the
-            ;; host.
+            ;; Create a dummy home directory.
             (mkdir-p home-dir)
             (setenv "HOME" home-dir)
 
@@ -475,7 +489,7 @@ symbolic link from ~/.guix-profile to the environment profile."
 
             ;; For convenience, start in the user's current working
             ;; directory rather than the root directory.
-            (chdir cwd)
+            (chdir (override-user-dir user home cwd))
 
             (primitive-exit/status
              ;; A container's environment is already purified, so no need to
@@ -485,6 +499,60 @@ symbolic link from ~/.guix-profile to the environment profile."
                            (delq 'net %namespaces) ; share host network
                            %namespaces)))))))
 
+(define (mock-passwd passwd user-override shell)
+  "Generate mock information for '/etc/passwd'.  If USER-OVERRIDE is not '#f',
+it is expected to be a string representing the mock username; it will produce
+a user of that name, with a home directory of '/home/USER-OVERRIDE', and no
+GECOS field.  If USER-OVERRIDE is '#f', data will be inherited from PASSWD.
+In either case, the shadow password and UID/GID are cleared, since the user
+runs as root within the container.  SHELL will always be used in place of the
+shell in PASSWD.
+
+The resulting vector is suitable for use with Guile's POSIX user procedures.
+
+See passwd(5) for more information each of the fields."
+  (if user-override
+      (vector
+       user-override
+        "x" "0" "0"  ;; no shadow, user is now root
+        ""           ;; no personal information
+        (user-override-home user-override)
+        shell)
+      (vector
+       (passwd:name passwd)
+        "x" "0" "0"  ;; no shadow, user is now root
+        (passwd:gecos passwd)
+        (passwd:dir passwd)
+        shell)))
+
+(define (user-override-home user)
+  "Return home directory for override user USER."
+  (string-append "/home/" user))
+
+(define (override-user-mappings user home mappings)
+  "If a username USER is provided, rewrite each HOME prefix in file system
+mappings MAPPINGS to a home directory determined by 'override-user-dir';
+otherwise, return MAPPINGS."
+  (if (not user)
+      mappings
+      (map (lambda (mapping)
+             (let ((target (file-system-mapping-target mapping)))
+               (if (string-prefix? home target)
+                   (file-system-mapping
+                    (source    (file-system-mapping-source mapping))
+                    (target    (override-user-dir user home target))
+                    (writable? (file-system-mapping-writable? mapping)))
+                   mapping)))
+           mappings)))
+
+(define (override-user-dir user home dir)
+  "If username USER is provided, overwrite string prefix HOME in DIR with a
+directory determined by 'user-override-home'; otherwise, return DIR."
+  (if (and user (string-prefix? home dir))
+      (string-append (user-override-home user)
+                     (substring dir (string-length home)))
+      dir))
+
 (define (link-environment profile home-dir)
   "Create a symbolic link from HOME-DIR/.guix-profile to PROFILE."
   (let ((profile-dir (string-append home-dir "/.guix-profile")))
@@ -572,6 +640,7 @@ message if any test fails."
            (container? (assoc-ref opts 'container?))
            (link-prof? (assoc-ref opts 'link-profile?))
            (network?   (assoc-ref opts 'network?))
+           (user       (assoc-ref opts 'user))
            (bootstrap? (assoc-ref opts 'bootstrap?))
            (system     (assoc-ref opts 'system))
            (command    (or (assoc-ref opts 'exec)
@@ -606,6 +675,8 @@ message if any test fails."
 
       (when (and (not container?) link-prof?)
         (leave (G_ "--link-prof cannot be used without --container~%")))
+      (when (and (not container?) user)
+        (leave (G_ "--user cannot be used without --container~%")))
 
       (with-store store
         (set-build-options-from-command-line store opts)
@@ -653,6 +724,7 @@ message if any test fails."
                                             "/bin/sh"))))
                     (launch-environment/container #:command command
                                                   #:bash bash-binary
+                                                  #:user user
                                                   #:user-mappings mappings
                                                   #:profile profile
                                                   #:paths paths
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index e995636df..a1ce96579 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -74,6 +74,16 @@ guix environment --bootstrap --ad-hoc guile-bootstrap --pure \
              -- guile -c "$linktest"
 )
 
+# Test that user can be mocked.
+usertest='(exit (and (string=? (getenv "HOME") "/home/foognu")
+                     (string=? (passwd:name (getpwuid 0)) "foognu")
+                     (file-exists? "/home/foognu/umock")))'
+touch "$tmpdir/umock"
+HOME="$tmpdir" guix environment --bootstrap --container --user=foognu \
+     --ad-hoc guile-bootstrap --pure \
+     --share="$tmpdir/umock" \
+     -- guile -c "$usertest"
+
 # Make sure '-r' works as expected.
 rm -f "$gcroot"
 expected="`guix environment --bootstrap --ad-hoc guile-bootstrap \
-- 
2.15.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 7358 bytes --]

* doc/guix.texi (Invoking guix environment): Add --no-cwd.
* guix/scripts/environment.scm (show-help, %options): Add --no-cwd.
(launch-environment/container): Add 'map-cwd?' param; only add mapping for cwd
if #t.  Only change to cwd within container if #t, otherwise home.
(guix-environment): Error if --no-cwd without --container.  Provide '(not
no-cwd?)' to launch-environment/container as 'map-cwd?'.
* tests/guix-environment.sh: Add test for no-cwd.
---
 doc/guix.texi                |  8 ++++++++
 guix/scripts/environment.scm | 33 ++++++++++++++++++++++++---------
 tests/guix-environment.sh    |  8 ++++++++
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 8218c6637..ce4545038 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -7209,6 +7209,14 @@ While this will limit the leaking of user identity through home paths
 and each of the user fields, this is only one useful component of a
 broader privacy/anonymity solution---not one in and of itself.
 
+@item --no-cwd
+For containers, the default behavior is to share the current working
+directory with the isolated container and immediately change to that
+directory within the container.  If this is undesirable, @code{--no-cwd}
+will cause the current working directory to @emph{not} be automatically
+shared and will change to the user's home directory within the container
+instead.  See also @code{--user}.
+
 @item --expose=@var{source}[=@var{target}]
 For containers, expose the file system @var{source} from the host system
 as the read-only file system @var{target} within the container.  If
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index f50018faf..6be263a64 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -165,6 +165,9 @@ COMMAND or an interactive shell in that environment.\n"))
   -u, --user=USER        instead of copying the name and home of the current
                          user into an isolated container, use the name USER
                          with home directory /home/USER"))
+  (display (G_ "
+      --no-cwd           do not share current working directory with an
+                         isolated container"))
   (display (G_ "
       --share=SPEC       for containers, share writable host file system
                          according to SPEC"))
@@ -251,6 +254,9 @@ COMMAND or an interactive shell in that environment.\n"))
                  (lambda (opt name arg result)
                    (alist-cons 'user arg
                                (alist-delete 'user result eq?))))
+         (option '("no-cwd") #f #f
+                 (lambda (opt name arg result)
+                   (alist-cons 'no-cwd? #t result)))
          (option '("share") #t #f
                  (lambda (opt name arg result)
                    (alist-cons 'file-system-mapping
@@ -399,7 +405,8 @@ environment variables are cleared before setting the new ones."
            ((_ . status) status)))))
 
 (define* (launch-environment/container #:key command bash user user-mappings
-                                       profile paths link-profile? network?)
+                                       profile paths link-profile? network?
+                                       map-cwd?)
   "Run COMMAND within a container that features the software in PROFILE.
 Environment variables are set according to PATHS, a list of native search
 paths.  The global shell is BASH, a file name for a GNU Bash binary in the
@@ -425,11 +432,13 @@ will be used for the passwd entry.  LINK-PROFILE? creates a symbolic link from
              (override-user-mappings
               user home
               (append user-mappings
-                      ;; Current working directory.
-                      (list (file-system-mapping
-                             (source cwd)
-                             (target cwd)
-                             (writable? #t)))
+                      ;; Share current working directory, unless asked not to.
+                      (if map-cwd?
+                          (list (file-system-mapping
+                                 (source cwd)
+                                 (target cwd)
+                                 (writable? #t)))
+                          '())
                       ;; When in Rome, do as Nix build.cc does: Automagically
                       ;; map common network configuration files.
                       (if network?
@@ -488,8 +497,10 @@ will be used for the passwd entry.  LINK-PROFILE? creates a symbolic link from
                 (newline port)))
 
             ;; For convenience, start in the user's current working
-            ;; directory rather than the root directory.
-            (chdir (override-user-dir user home cwd))
+            ;; directory or, if unmapped, the home directory.
+            (chdir (if map-cwd?
+                       (override-user-dir user home cwd)
+                       home-dir))
 
             (primitive-exit/status
              ;; A container's environment is already purified, so no need to
@@ -640,6 +651,7 @@ message if any test fails."
            (container? (assoc-ref opts 'container?))
            (link-prof? (assoc-ref opts 'link-profile?))
            (network?   (assoc-ref opts 'network?))
+           (no-cwd?    (assoc-ref opts 'no-cwd?))
            (user       (assoc-ref opts 'user))
            (bootstrap? (assoc-ref opts 'bootstrap?))
            (system     (assoc-ref opts 'system))
@@ -677,6 +689,8 @@ message if any test fails."
         (leave (G_ "--link-prof cannot be used without --container~%")))
       (when (and (not container?) user)
         (leave (G_ "--user cannot be used without --container~%")))
+      (when (and (not container?) no-cwd?)
+        (leave (G_ "--no-cwd cannot be used without --container~%")))
 
       (with-store store
         (set-build-options-from-command-line store opts)
@@ -729,7 +743,8 @@ message if any test fails."
                                                   #:profile profile
                                                   #:paths paths
                                                   #:link-profile? link-prof?
-                                                  #:network? network?)))
+                                                  #:network? network?
+                                                  #:map-cwd? (not no-cwd?))))
                  (else
                   (return
                    (exit/status
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index a1ce96579..abb019794 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -84,6 +84,14 @@ HOME="$tmpdir" guix environment --bootstrap --container --user=foognu \
      --share="$tmpdir/umock" \
      -- guile -c "$usertest"
 
+# if not sharing CWD, chdir home
+(
+  cd "$tmpdir" \
+    && guix environment --bootstrap --container --no-cwd --user=foo  \
+            --ad-hoc guile-bootstrap --pure \
+            -- /bin/sh -c 'test $(pwd) == "/home/foo" -a ! -d '"$tmpdir"
+)
+
 # Make sure '-r' works as expected.
 rm -f "$gcroot"
 expected="`guix environment --bootstrap --ad-hoc guile-bootstrap \
-- 
2.15.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 5053 bytes --]

On Thu, Jan 25, 2018 at 23:16:47 +0100, Ludovic Courtès wrote:
> If you drop the attached file under guix/scripts/, you can then run:
>
>   guix run icecat icecat
>
> and similar.  This particular example doesn’t work well because of the
> font issue you’re familiar with, but you get the idea.  :-)

Oh, this is interesting.  I won't get a chance to try this out until
tomorrow, but I think it's a good start.

I sent a few patches moments ago that I've been sitting on for a
bit.  My intent was originally to go further, but I ran out of
time.  But I didn't think `guix environment' was the appropriate place
to put such things---this script, though, is a good starting point for
them.

For example, if one of the dependencies of a program is X11, it can
automatically share the X paths (unless overridden by the user).  Same
with DBUS, sound devices, etc.  I mentioned previous ideas earlier in
the thread.

I'd also want to integrate changes I made to `guix environment'.  If
people here like the changes and they are merged, I'd want to refactor
it into a common place, not just copy the code.

I think this gives us a lot to move forward with, and some good
discussion to have.  A lot of subtle details will have to be worked out,
like what default behavior should be.


Anyway, here's what I have so far.  I still have to get sound working; I
took a pause on that, not having spent more than a few minutes on it;
I'll get back to it hopefully in the next few days.  If anyone else
knows exactly what needs to be done, please lmk.


#+BEGIN_SRC sh
~/guix/pre-inst-env guix environment \
     --container \
     --link-profile \
     --no-cwd \
     --user=user \
     --network \
     -r "$gc_root" \
     --expose=/etc/machine-id \
     --expose=/tmp/.X11-unix/ \
     --expose=$HOME/.Xauthority \
     --share=/dev/snd \
     --share=$HOME/.mozilla/ \
     --share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \
     --ad-hoc mtg-icecat-containerized  \
     -- \
     icecat --display=:0.0 "$@" \
#+END_SRC


#+BEGIN_SRC scheme
(define-module (mtg personal)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (gnu packages)
  #:use-module (guix build-system trivial)
  #:use-module (gnu packages gnome)
  #:use-module (gnu packages gnuzilla)
  #:use-module (gnu packages fonts)
  #:use-module (gnu packages fontutils)
  #:use-module (gnu packages pulseaudio))


(define-public mtg-icecat-containerized
  (package
    (name "mtg-icecat-containerized")
    (version "1.0")
    (home-page "https://mikegerwitz.com/")
    (build-system trivial-build-system)
    (source #f)
    (native-inputs
     `(("fontconfig" ,fontconfig)))
    (build-system trivial-build-system)
    (arguments
     `(#:modules ((guix build utils))
       #:builder
       (begin
         (use-modules (guix build utils))
         (let* ((share-dir (string-append %output "/share"))
                (cache-dir (string-append %output "/var/cache"))
                (bin-dir   (string-append %output "/bin"))
                (fc-dir    (string-append share-dir "/fontconfig/conf.avail"))
                (fc-mtg    (string-append fc-dir "/52-mtg-container.conf"))
                (fc-cache-dir (string-append cache-dir "/fontconfig"))
                (fonts-dir (string-append share-dir "/fonts")))
           ;; container script to invoke IceCat
           (mkdir-p bin-dir)
           (call-with-output-file (string-append bin-dir "icecat-container")
             (lambda (port)
               (format port "#!/bin/bash")))

           ;; fontconfig configuration
           (mkdir-p fc-dir)
           (call-with-output-file fc-mtg
             (lambda (port)
               (format port (string-append "<?xml version=\"1.0\"?>
<!DOCTYPE fontconfig SYSTEM \"fonts.dtd\">
<fontconfig>
  <dir>" (string-append (assoc-ref %build-inputs "font-dejavu")
                        "/share/fonts") "</dir>
  <cachedir>" fc-cache-dir "</cachedir>
</fontconfig>\n"))))

           (setenv "PATH"
                   (string-append (assoc-ref %build-inputs "fontconfig")
                                  "/bin"))
           (setenv "FONTCONFIG_FILE" fc-mtg)
           (setenv "XDG_DATA_HOME" share-dir)

           (mkdir-p cache-dir)
           (invoke "fc-cache" "-fv")))))
    (propagated-inputs
     `(("icecat" ,icecat)
       ("zenity" ,zenity)
       ("font-dejavu" ,font-dejavu)
       ("pulseaudio" ,pulseaudio)
       ;;("font-adobe-source-han-sans", font-adobe-source-han-sans)
       ))
    (synopsis "GNU IceCat packaged for running within a container")
    (description
     "GNU IceCat packaged with various fonts (including multi-lingual).
Suitable for use within a container.")
    (license license:gpl3+)))
#+END_SRC

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[Ludovic Courtès]

Heya,

Mike Gerwitz <mtg@gnu.org> skribis:

> On Thu, Jan 25, 2018 at 23:16:47 +0100, Ludovic Courtès wrote:
>> If you drop the attached file under guix/scripts/, you can then run:
>>
>>   guix run icecat icecat
>>
>> and similar.  This particular example doesn’t work well because of the
>> font issue you’re familiar with, but you get the idea.  :-)

I also realized that we can support:

  guix run icecat

which looks up ‘icecat’ in $PATH, and “readlink -f” to get at the
underlying store item.  This would be faster (and probably more
convenient) than “building” icecat as the script currently does.

> I sent a few patches moments ago that I've been sitting on for a
> bit.  My intent was originally to go further, but I ran out of
> time.  But I didn't think `guix environment' was the appropriate place
> to put such things---this script, though, is a good starting point for
> them.

Agreed.  I like the ideas in the patches you sent, but I’m not sure
‘guix environment’ is the right place for them.  It goes beyond the
typical job of ‘guix environment’.

> For example, if one of the dependencies of a program is X11, it can
> automatically share the X paths (unless overridden by the user).  Same
> with DBUS, sound devices, etc.  I mentioned previous ideas earlier in
> the thread.

Indeed, that’s a good idea.  It may be good enough to pattern-match the
store file names.

The attached version follows this suggestion:

--8<---------------cut here---------------start------------->8---
ludo@ribbon ~/src/guix$ ./pre-inst-env guix run xdpyinfo |head

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    11906000
X.Org version: 1.19.6
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
ludo@ribbon ~/src/guix$ ./pre-inst-env guix run ls -la .

total 0
drwxr-xr-x 2 0 0 40 Jan 29 16:40 .
drwxr-xr-x 3 0 0 60 Jan 29 16:40 ..
--8<---------------cut here---------------end--------------->8---

For some reason IceCat and Evince crash with a GDK error, whereas GIMP
and Xpdf are fine.

> I'd also want to integrate changes I made to `guix environment'.  If
> people here like the changes and they are merged, I'd want to refactor
> it into a common place, not just copy the code.

Yes, it’d be nice to have a module of utilities for environment
management.

>            ;; container script to invoke IceCat
>            (mkdir-p bin-dir)
>            (call-with-output-file (string-append bin-dir "icecat-container")
>              (lambda (port)
>                (format port "#!/bin/bash")))
>
>            ;; fontconfig configuration
>            (mkdir-p fc-dir)
>            (call-with-output-file fc-mtg
>              (lambda (port)
>                (format port (string-append "<?xml version=\"1.0\"?>
> <!DOCTYPE fontconfig SYSTEM \"fonts.dtd\">
> <fontconfig>
>   <dir>" (string-append (assoc-ref %build-inputs "font-dejavu")
>                         "/share/fonts") "</dir>
>   <cachedir>" fc-cache-dir "</cachedir>
> </fontconfig>\n"))))
>
>            (setenv "PATH"
>                    (string-append (assoc-ref %build-inputs "fontconfig")
>                                   "/bin"))
>            (setenv "FONTCONFIG_FILE" fc-mtg)
>            (setenv "XDG_DATA_HOME" share-dir)
>
>            (mkdir-p cache-dir)
>            (invoke "fc-cache" "-fv")))))

Nice!

Actually there are really two approaches we could use.  One is to create
wrappers like this one that do the right thing, independently of what
the user’s profile contains (‘guix package’ could even generate wrappers
automatically in some cases.)

The second approach is a ‘guix run/environment’ kind of command that
generates the environment at run time.

There are pros and cons to both, I think.

Food for thought!

Thanks,
Ludo’.

Re: Running IceCat in a container

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 37 bytes --]

And the attachment…

Ludo’.


[-- Attachment #2: the 'guix run' command --]
[-- Type: text/plain, Size: 5709 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Ludovic Courtès <ludo@gnu.org>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (guix scripts run)
  #:use-module (guix ui)
  #:use-module (guix utils)
  #:use-module (guix scripts)
  #:use-module (guix store)
  #:use-module (guix packages)
  #:use-module (guix derivations)
  #:use-module ((guix build utils) #:select (which mkdir-p))
  #:use-module (gnu build linux-container)
  #:use-module (gnu system file-systems)
  #:use-module (gnu packages)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-11)
  #:use-module (srfi srfi-26)
  #:use-module (srfi srfi-37)
  #:use-module (ice-9 match)
  #:export (guix-run))

(define %options
  (list (option '(#\h "help") #f #f
                (lambda args
                  (show-help)
                  (exit 0)))
        (option '(#\V "version") #f #f
                (lambda args
                  (show-version-and-exit "guix run")))))

(define (show-help)
  (display (G_ "Usage: guix run PACKAGE COMMAND...
Run COMMAND from PACKAGE in a container.\n"))
  (newline)
  (display (G_ "
  -h, --help             display this help and exit"))
  (display (G_ "
  -V, --version          display version information and exit"))
  (newline)
  (show-bug-report-information))

\f

(define (bind-mount-spec/ro item)
  (and (file-exists? item)
       (file-system
         (device item)
         (mount-point item)
         (title 'device)
         (type "none")
         (flags '(bind-mount read-only))
         (check? #f))))

(define (bind-mount-spec/rw item)
  (and (file-exists? item)
       (file-system
         (inherit (bind-mount-spec/ro item))
         (flags '(bind-mount)))))

(define (application-file-system-mappings items)
  "Return the list of <file-system> objects corresponding to bind mounts
required by the applications whose dependencies are listed in ITEMS."
  (define packages
    (map (compose (cut package-name->name+version <> #\-)
                  store-path-package-name)
         items))

  (define x11? (member "libx11" packages))
  (define dbus? (member "dbus" packages))
  (define alsa? (member "alsa-lib" packages))
  (define pulseaudio? (member "pulseaudio" packages))

  (let-syntax ((if (syntax-rules ()
                     ((_ condition body)
                      (if condition (list body) '()))))
               (ro (identifier-syntax bind-mount-spec/ro))
               (rw (identifier-syntax bind-mount-spec/rw)))
    `(,(rw "/var/run/nscd/socket")
      ,@(if x11? (rw (string-append (getenv "HOME") "/.Xauthority")))
      ,@(if x11? (rw "/tmp/.X11-unix"))
      ,@(if dbus? (ro "/etc/machine-id"))
      ,@(if alsa? (rw "/dev/snd"))
      ,@(if pulseaudio? (rw (string-append (getenv "HOME") "/.pulse"))))))

(define %not-colon
  (char-set-complement (char-set #\:)))

(define (guix-run . args)
  (define (parse-options)
    ;; Return the alist of option values.  With this hack, the first
    ;; non-option argument is considered to be the beginning of the command.
    (let-values (((args command) (span (cut string-prefix? "-" <>) args)))
      (args-fold* args %options
                  (lambda (opt name arg result)
                    (leave (G_ "~A: unrecognized option~%") name))
                  (lambda (arg result)
                    (pk 'arg arg)
                    (alist-cons 'argument arg result))
                  '())
      command))

  (with-error-handling
    (match (parse-options)
      ((command args ...)
       (with-store store
         (let* ((full     (search-path (string-tokenize (getenv "PATH") %not-colon)
                                       command))
                (resolved (and=> full readlink*))
                (prefix   (and=> resolved (lambda (file)
                                            (and (store-path? file)
                                                 (direct-store-path file))))))
           (unless full
             (leave (G_ "command '~a' not found~%") command))
           (unless prefix
             (leave (G_ "command '~a' is not in '~a'~%")
                    command (%store-prefix)))

           (let ((items (requisites store (list prefix)))
                 (env   (environ)))

             (call-with-container
                 (append (map bind-mount-spec/ro items)
                         (application-file-system-mappings items))
               (lambda ()
                 (environ env)                    ;TODO: filter ENV
                 (mkdir-p (getenv "HOME"))
                 (chdir (getenv "HOME"))

                 (newline)
                 (catch #t
                   (lambda ()
                     (apply execl resolved command args))
                   (lambda (key . args)
                     (print-exception (current-error-port) #f key args)
                     (exit 1))))
               #:namespaces (delq 'net %namespaces)))))))))

Re: Running IceCat in a container

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Actually there are really two approaches we could use.  One is to create
> wrappers like this one that do the right thing, independently of what
> the user’s profile contains (‘guix package’ could even generate wrappers
> automatically in some cases.)
>
> The second approach is a ‘guix run/environment’ kind of command that
> generates the environment at run time.
>
> There are pros and cons to both, I think.

This is just a tangent:

I’ve been thinking that “guix run” (or an extension of “guix container”)
would be great not only for running applications in containers that are
*already* in the store, but also to run applications from tarballs that
were generated with "guix pack“.

    pack=$(guix pack $(readlink -f $HOME/.guix-profile) -S /bin=bin)
    guix run --image=${pack} /bin/icecat

Look, we’ve got our own container image format! :) This seems to cover
85% of all uses of Docker/Singularity in the field of bioinformatics.

~~~

The setup to create configuration files and set environment variables so
that the target application feels at home in the container — that all
looks an awful lot like profile hooks to me.  Maybe we can have a set of
common hooks that we can automatically derive from package inputs?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Running code from packs in containers

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Actually there are really two approaches we could use.  One is to create
>> wrappers like this one that do the right thing, independently of what
>> the user’s profile contains (‘guix package’ could even generate wrappers
>> automatically in some cases.)
>>
>> The second approach is a ‘guix run/environment’ kind of command that
>> generates the environment at run time.
>>
>> There are pros and cons to both, I think.
>
> This is just a tangent:
>
> I’ve been thinking that “guix run” (or an extension of “guix container”)
> would be great not only for running applications in containers that are
> *already* in the store, but also to run applications from tarballs that
> were generated with "guix pack“.
>
>     pack=$(guix pack $(readlink -f $HOME/.guix-profile) -S /bin=bin)
>     guix run --image=${pack} /bin/icecat
>
> Look, we’ve got our own container image format! :) This seems to cover
> 85% of all uses of Docker/Singularity in the field of bioinformatics.

Indeed, very good point!

> The setup to create configuration files and set environment variables so
> that the target application feels at home in the container — that all
> looks an awful lot like profile hooks to me.  Maybe we can have a set of
> common hooks that we can automatically derive from package inputs?

Sounds like search paths no?  Or maybe a bit of both?

Anyway, it wouldn’t cost us much so to speak, so it’s worth looking into
that.

Ludo’.

bug#30255: [PATCH 1/3] scripts: environment: Add --link-profile.

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

Hi Mike,

Mike Gerwitz <mtg@gnu.org> skribis:

> This change is motivated by attempts to run programs (like GNU IceCat) within
> containers.  The 'fontconfig' program, for example, is configured explicitly
> to check ~/.guix-profile for additional fonts.
>
> There were no existing container tests in 'tests/guix-environment.sh', but I
> added one anyway for this change.
>
> * doc/guix.texi (Invoking guix environment): Add '--link-profile'.
> * guix/scripts/environment.scm (show-help): Add '--link-profile'.
> (%options): Add 'link-profile' as '#\P', assigned to 'link-profile?'.
> (lnk-environment): New procedure.
> (launch-environment/container): Use it when 'link-profile?'.
> [link-profile?]: New parameter.
> (guix-environment): Leave when '--link-prof' but not '--container'.  Add
> '#:link-profile?' argument to 'launch-environment/container' application.
> * tests/guix-environment.sh: New '--link-profile' test.

Sorry for forgetting about this patch series.  It’s perfect, and
very useful!

I applied this one with the changes below.  The main change is moving
the test to guix-environment-container.sh, which is skipped when user
namespaces are not supported.

Thank you!

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2761 bytes --]

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index d86d30308..5c7d83881 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -513,7 +513,7 @@ symbolic link from ~/.guix-profile to the environment profile."
         (symlink profile profile-dir))
       (lambda args
         (if (= EEXIST (system-error-errno args))
-            (leave (G_ "cannot link profile: path '~a' already exists within container~%")
+            (leave (G_ "cannot link profile: '~a' already exists within container~%")
                    profile-dir)
             (apply throw args))))))
 
@@ -625,7 +625,7 @@ message if any test fails."
       (when container? (assert-container-features))
 
       (when (and (not container?) link-prof?)
-        (leave (G_ "--link-prof cannot be used without --container~%")))
+        (leave (G_ "'--link-profile' cannot be used without '--container'~%")))
 
       (with-store store
         (set-build-options-from-command-line store opts)
diff --git a/tests/guix-environment-container.sh b/tests/guix-environment-container.sh
index d7c1b7057..df40ce03e 100644
--- a/tests/guix-environment-container.sh
+++ b/tests/guix-environment-container.sh
@@ -97,6 +97,20 @@ grep -e "$NIX_STORE_DIR/.*-bash" $tmpdir/mounts # bootstrap bash
 
 rm $tmpdir/mounts
 
+# Make sure 'GUIX_ENVIRONMENT' is linked to '~/.guix-profile' when requested
+# within a container.
+(
+  linktest='(exit (string=? (getenv "GUIX_ENVIRONMENT")
+(readlink (string-append (getenv "HOME") "/.guix-profile"))))'
+
+  cd "$tmpdir" \
+     && guix environment --bootstrap --container --link-profile \
+             --ad-hoc guile-bootstrap --pure \
+             -- guile -c "$linktest"
+)
+
+# Check the exit code.
+
 abnormal_exit_code="
 (use-modules (system foreign))
 ;; Purposely make Guile crash with a segfault. :)
diff --git a/tests/guix-environment.sh b/tests/guix-environment.sh
index ba686816f..b44aca099 100644
--- a/tests/guix-environment.sh
+++ b/tests/guix-environment.sh
@@ -71,18 +71,6 @@ echo "(use-modules (guix profiles) (gnu packages bootstrap))
 guix environment --bootstrap --manifest=$tmpdir/manifest.scm --pure \
      -- "$SHELL" -c 'test -f "$GUIX_ENVIRONMENT/bin/guile"'
 
-# Make sure 'GUIX_ENVIRONMENT' is linked to '~/.guix-profile' when requested
-# within a container
-(
-  linktest='(exit (string=? (getenv "GUIX_ENVIRONMENT")
-(readlink (string-append (getenv "HOME") "/.guix-profile"))))'
-
-  cd "$tmpdir" \
-     && guix environment --bootstrap --container --link-profile \
-             --ad-hoc guile-bootstrap --pure \
-             -- guile -c "$linktest"
-)
-
 # Make sure '-r' works as expected.
 rm -f "$gcroot"
 expected="`guix environment --bootstrap --ad-hoc guile-bootstrap \

[bug#30257] [PATCH 2/3] scripts: environment: Add --user.

[Ludovic Courtès]

Mike Gerwitz <mtg@gnu.org> skribis:

> This change allows overriding the home directory of all filesystem mappings to
> help hide the identity of the calling user in a container.
>
> * doc/guix.texi (Invoking guix environment)[--container]: Mention --user.
> [--user]: Add item.
> * guix/scripts/environment.scm (show-help): Add --user.
> (%options): Add --user.
> (launch-environment/container) Add 'user' parameter.  Update doc.  Override
> 'user-mappings' using 'override-user-mappings'.  Consider override for chdir.
> (mock-passwd, user-override-home, overrid-euser-dir): New procedures.
> (guix-environment): Disallow --user without --container.  Provide user to
> 'launch-environment/container'.
> * tests/guix-environment.sh: Add user test.

Awesome, I moved the test to guix-environment-container.sh and applied.

Ludo’.

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

Mike Gerwitz <mtg@gnu.org> skribis:

> * doc/guix.texi (Invoking guix environment): Add --no-cwd.
> * guix/scripts/environment.scm (show-help, %options): Add --no-cwd.
> (launch-environment/container): Add 'map-cwd?' param; only add mapping for cwd
> if #t.  Only change to cwd within container if #t, otherwise home.
> (guix-environment): Error if --no-cwd without --container.  Provide '(not
> no-cwd?)' to launch-environment/container as 'map-cwd?'.
> * tests/guix-environment.sh: Add test for no-cwd.

This one LGTM as well (with the test moved to
guix-environment-container.sh).  There’s just a minor issue:

> --- a/tests/guix-environment.sh
> +++ b/tests/guix-environment.sh
> @@ -84,6 +84,14 @@ HOME="$tmpdir" guix environment --bootstrap --container --user=foognu \
>       --share="$tmpdir/umock" \
>       -- guile -c "$usertest"
>  
> +# if not sharing CWD, chdir home
> +(
> +  cd "$tmpdir" \
> +    && guix environment --bootstrap --container --no-cwd --user=foo  \
> +            --ad-hoc guile-bootstrap --pure \
> +            -- /bin/sh -c 'test $(pwd) == "/home/foo" -a ! -d '"$tmpdir"
> +)
> +

This test would fail for me because my test store is at
~ludo/src/guix/test-tmp/store and my CWD is ~/src/guix.  So when using
both --user and --no-cwd, the effect is that
~ludo/src/guix/test-tmp/store is not available at all within the
container, and thus execve("/bin/sh") fails with ENOENT:

--8<---------------cut here---------------start------------->8---
$ ./test-env guix environment --bootstrap --container --no-cwd --user=foo --ad-hoc guile-bootstrap
accepted connection from pid 29684, user ludo
accepted connection from pid 29695, user ludo
./test-env: line 1: 29683 Terminated              "/home/ludo/src/guix/pre-inst-env" "/home/ludo/src/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
$ echo $?
1
--8<---------------cut here---------------end--------------->8---

Thoughts?

TIA,
Ludo’.

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

Hey, Ludo!

Sorry I've been silent on the script you provided to me---between my GNU
volunteer work and preparing for my LP2018 talk, I've had no free time,
so I haven't even looked at it yet.  After the conference I'll have the
time to collaborate a bit more.

Also---I thought the decision was that this patchset was inappropriate
for `guix environment`; did I misinterpret?

On Fri, Mar 02, 2018 at 11:54:30 +0100, Ludovic Courtès wrote:
>> --- a/tests/guix-environment.sh
>> +++ b/tests/guix-environment.sh
>> @@ -84,6 +84,14 @@ HOME="$tmpdir" guix environment --bootstrap --container --user=foognu \
>>       --share="$tmpdir/umock" \
>>       -- guile -c "$usertest"
>>  
>> +# if not sharing CWD, chdir home
>> +(
>> +  cd "$tmpdir" \
>> +    && guix environment --bootstrap --container --no-cwd --user=foo  \
>> +            --ad-hoc guile-bootstrap --pure \
>> +            -- /bin/sh -c 'test $(pwd) == "/home/foo" -a ! -d '"$tmpdir"
>> +)
>> +
>
> This test would fail for me because my test store is at
> ~ludo/src/guix/test-tmp/store and my CWD is ~/src/guix.  So when using
> both --user and --no-cwd, the effect is that
> ~ludo/src/guix/test-tmp/store is not available at all within the
> container, and thus execve("/bin/sh") fails with ENOENT:
>
> $ ./test-env guix environment --bootstrap --container --no-cwd --user=foo --ad-hoc guile-bootstrap
> accepted connection from pid 29684, user ludo
> accepted connection from pid 29695, user ludo
> ./test-env: line 1: 29683 Terminated              "/home/ludo/src/guix/pre-inst-env" "/home/ludo/src/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
> $ echo $?
> 1
>
> Thoughts?

I admit that I forgot some of the implementation details of my own
patch; I'd have to look at it in more detail.  I'll consider it tonight
or this weekend.

Thanks for taking a look at and applying these.  If there are better
solutions, I'm fine with that---I just wanted a proof-of-concept to
start the discussion.  Though, starting the discussion and then ducking
out for other obligations wasn't quite what I had in mind...

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

Hi Mike,

Mike Gerwitz <mtg@gnu.org> skribis:

> Sorry I've been silent on the script you provided to me---between my GNU
> volunteer work and preparing for my LP2018 talk, I've had no free time,
> so I haven't even looked at it yet.  After the conference I'll have the
> time to collaborate a bit more.

Sure, understood!

> Also---I thought the decision was that this patchset was inappropriate
> for `guix environment`; did I misinterpret?

My initial reaction was that we shouldn’t stretch ‘guix environment’ to
do something that’s unrelated to environment management.

However as I looked at your patches, I found that the additions you made
are useful per se (for instance I’ve been wanting ‘--link-profile’ on a
couple of occasions for reasons like the one you gave, Fontconfig,
etc.).  And the patches had tests, documentation, and everything, so it
seemed more beneficial to include them.  :-)

> I admit that I forgot some of the implementation details of my own
> patch; I'd have to look at it in more detail.  I'll consider it tonight
> or this weekend.

OK!

> Thanks for taking a look at and applying these.  If there are better
> solutions, I'm fine with that---I just wanted a proof-of-concept to
> start the discussion.  Though, starting the discussion and then ducking
> out for other obligations wasn't quite what I had in mind...

Sure.  I think the issue of least-authority execution of programs
remains open anway.  Do we want a ‘guix run’-like command?  Something in
the shell, but which shell(s) then?  Automatically-generated wrappers so
we don’t depend on specific shells?

Thanks,
Ludo’.

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Sat, Mar 03, 2018 at 15:44:43 +0100, Ludovic Courtès wrote:
>> Also---I thought the decision was that this patchset was inappropriate
>> for `guix environment`; did I misinterpret?
>
> My initial reaction was that we shouldn’t stretch ‘guix environment’ to
> do something that’s unrelated to environment management.
>
> However as I looked at your patches, I found that the additions you made
> are useful per se (for instance I’ve been wanting ‘--link-profile’ on a
> couple of occasions for reasons like the one you gave, Fontconfig,
> etc.).  And the patches had tests, documentation, and everything, so it
> seemed more beneficial to include them.  :-)

Okay, sounds good.

>> Thanks for taking a look at and applying these.  If there are better
>> solutions, I'm fine with that---I just wanted a proof-of-concept to
>> start the discussion.  Though, starting the discussion and then ducking
>> out for other obligations wasn't quite what I had in mind...
>
> Sure.  I think the issue of least-authority execution of programs
> remains open anway.  Do we want a ‘guix run’-like command?  Something in
> the shell, but which shell(s) then?  Automatically-generated wrappers so
> we don’t depend on specific shells?

One thing in particular about using `guix environment --ad-hoc' that is
particularly unfortunate with how I'm abusing it is that it will build
new derivations as necessary (as it is supposed to).  So "starting
icecat" in a container isn't just that.  I recently upgraded Guix, and
icecat isn't available on Hydra yet, so I'm unable to start icecat at
all until it compiles, which is hours on an X200 (though I'm assuming
that reverting ~/.config/guix/latest might allow me to work around it
temporarily with an old version).  This would not have been a problem
with a normal icecat installation in my profile.

Obviously the desirable behavior is to just containerize whatever is in
your profile, if possible.  Maybe the script you sent me does just
that.  I'm excited to play around with it, I just can't atm. :(

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

Heya,

Mike Gerwitz <mtg@gnu.org> skribis:

> On Sat, Mar 03, 2018 at 15:44:43 +0100, Ludovic Courtès wrote:

[...]

>> Sure.  I think the issue of least-authority execution of programs
>> remains open anway.  Do we want a ‘guix run’-like command?  Something in
>> the shell, but which shell(s) then?  Automatically-generated wrappers so
>> we don’t depend on specific shells?
>
> One thing in particular about using `guix environment --ad-hoc' that is
> particularly unfortunate with how I'm abusing it is that it will build
> new derivations as necessary (as it is supposed to).  So "starting
> icecat" in a container isn't just that.  I recently upgraded Guix, and
> icecat isn't available on Hydra yet, so I'm unable to start icecat at
> all until it compiles, which is hours on an X200 (though I'm assuming
> that reverting ~/.config/guix/latest might allow me to work around it
> temporarily with an old version).  This would not have been a problem
> with a normal icecat installation in my profile.

Right.  The ‘guix run’ script I sent doesn’t try to build things; it
just takes whatever is in $PATH (which has to be in the store,
ultimately) and runs it.

> Obviously the desirable behavior is to just containerize whatever is in
> your profile, if possible.  Maybe the script you sent me does just
> that.  I'm excited to play around with it, I just can't atm. :(

You still have to explicitly run ‘guix run icecat’, which isn’t great:
if you’re using GNOME Shell and clicking on the icon, you don’t get to
run it in a containerized environment.

Ludo’.

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

On Sun, Mar 04, 2018 at 23:24:27 +0100, Ludovic Courtès wrote:
> Right.  The ‘guix run’ script I sent doesn’t try to build things; it
> just takes whatever is in $PATH (which has to be in the store,
> ultimately) and runs it.

Oh, great!

>> Obviously the desirable behavior is to just containerize whatever is in
>> your profile, if possible.  Maybe the script you sent me does just
>> that.  I'm excited to play around with it, I just can't atm. :(
>
> You still have to explicitly run ‘guix run icecat’, which isn’t great:
> if you’re using GNOME Shell and clicking on the icon, you don’t get to
> run it in a containerized environment.

Well, I do everything from a shell, so that works for me personally. :)
But yes, what you are describing is important.

But, from a security perspective, I'd like for containerization to be
_guaranteed_, otherwise a malicious script could just subvert it
(e.g. open icecat with an argument to a malicious HTML file).  I used
`guix environment` not only because of its container support, but
because that ensured that icecat wasn't in my profile at all to be
invoked by something else.

Currently, I'd have to write a package definition to add a wrapper; that
wouldn't be done automatically for me.  But considering a functional
package manager, it'd be an interesting problem to try to get around
that.  And you don't want containerized versions of _every_
package---that's some serious bloat.  Unless maybe they're packages that
are generated from existing package definitions (in some
yet-to-be-defined manner), and maybe those packages have a special
containerized output (in addition to `out',
e.g. `icecat:container').  (I suppose short-term, such outputs can be
created manually for select packages.)

Just spewing thoughts.  I'm still not well-versed in Guix.  So maybe
`guix run` is a good starting point and can be used by a wrapper in the
future.  It also allows users to containerize something optionally---for
example, maybe a user doesn't want to containerize their PDF reader, but
if they are opening an untrusted PDF, they'll want to.  A GNOME context
menu option to say "Open in isolated container" (sorta like Qubes)
sounds attractive.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

Hello,

Mike Gerwitz <mtg@gnu.org> skribis:

> On Sun, Mar 04, 2018 at 23:24:27 +0100, Ludovic Courtès wrote:

[...]

>> You still have to explicitly run ‘guix run icecat’, which isn’t great:
>> if you’re using GNOME Shell and clicking on the icon, you don’t get to
>> run it in a containerized environment.
>
> Well, I do everything from a shell, so that works for me personally. :)
> But yes, what you are describing is important.
>
> But, from a security perspective, I'd like for containerization to be
> _guaranteed_, otherwise a malicious script could just subvert it
> (e.g. open icecat with an argument to a malicious HTML file).  I used
> `guix environment` not only because of its container support, but
> because that ensured that icecat wasn't in my profile at all to be
> invoked by something else.

Good point.

> Currently, I'd have to write a package definition to add a wrapper; that
> wouldn't be done automatically for me.  But considering a functional
> package manager, it'd be an interesting problem to try to get around
> that.  And you don't want containerized versions of _every_
> package---that's some serious bloat.  Unless maybe they're packages that
> are generated from existing package definitions (in some
> yet-to-be-defined manner), and maybe those packages have a special
> containerized output (in addition to `out',
> e.g. `icecat:container').  (I suppose short-term, such outputs can be
> created manually for select packages.)

I was thinking ‘guix package’ could create those wrappers automatically
based on a number of criteria: a package property could request
containerization, command-line options could disable that, and so on.

> Just spewing thoughts.  I'm still not well-versed in Guix.  So maybe
> `guix run` is a good starting point and can be used by a wrapper in the
> future.  It also allows users to containerize something optionally---for
> example, maybe a user doesn't want to containerize their PDF reader, but
> if they are opening an untrusted PDF, they'll want to.  A GNOME context
> menu option to say "Open in isolated container" (sorta like Qubes)
> sounds attractive.

Yeah, though I very much think least authority would be a better default
than ambient authority.  :-)

Ludo’.

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Tue, Mar 06, 2018 at 11:20:23 +0100, Ludovic Courtès wrote:
> Mike Gerwitz <mtg@gnu.org> skribis:
>> Currently, I'd have to write a package definition to add a wrapper; that
>> wouldn't be done automatically for me.  But considering a functional
>> package manager, it'd be an interesting problem to try to get around
>> that.  And you don't want containerized versions of _every_
>> package---that's some serious bloat.  Unless maybe they're packages that
>> are generated from existing package definitions (in some
>> yet-to-be-defined manner), and maybe those packages have a special
>> containerized output (in addition to `out',
>> e.g. `icecat:container').  (I suppose short-term, such outputs can be
>> created manually for select packages.)
>
> I was thinking ‘guix package’ could create those wrappers automatically
> based on a number of criteria: a package property could request
> containerization, command-line options could disable that, and so on.

Yes, I'd much prefer that.  That package definition might not be able to
infer certain things, so we'd need to be able to specify e.g. paths to
include in the container.  Preferably overridable as well---for example,
I don't share ~/.cache/mozilla/icecat with the container (I want it to
be ephemeral), but other users may prefer to.

>> Just spewing thoughts.  I'm still not well-versed in Guix.  So maybe
>> `guix run` is a good starting point and can be used by a wrapper in the
>> future.  It also allows users to containerize something optionally---for
>> example, maybe a user doesn't want to containerize their PDF reader, but
>> if they are opening an untrusted PDF, they'll want to.  A GNOME context
>> menu option to say "Open in isolated container" (sorta like Qubes)
>> sounds attractive.
>
> Yeah, though I very much think least authority would be a better default
> than ambient authority.  :-)

I agree for my needs; I suppose we'd need to see what downsides exist
from containerization (if any) that might make the user think
otherwise.  If containerization by default is suitable, then there may
be no need to provide a non-container option, so long as the user can
choose paths to share with the container (and network access).  This is
sounding more like an AppArmor type of permission system.  (Without the
AppArmor, of course.)

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Running IceCat in a container

[ng0]

Ludovic Courtès transcribed 4.0K bytes:
> Heya,
> 
> Mike Gerwitz <mtg@gnu.org> skribis:
> 
> > On Thu, Jan 25, 2018 at 23:16:47 +0100, Ludovic Courtès wrote:
> >> If you drop the attached file under guix/scripts/, you can then run:
> >>
> >>   guix run icecat icecat
> >>
> >> and similar.  This particular example doesn’t work well because of the
> >> font issue you’re familiar with, but you get the idea.  :-)
> 
> I also realized that we can support:
> 
>   guix run icecat
> 
> which looks up ‘icecat’ in $PATH, and “readlink -f” to get at the
> underlying store item.  This would be faster (and probably more
> convenient) than “building” icecat as the script currently does.
> 
> > I sent a few patches moments ago that I've been sitting on for a
> > bit.  My intent was originally to go further, but I ran out of
> > time.  But I didn't think `guix environment' was the appropriate place
> > to put such things---this script, though, is a good starting point for
> > them.
> 
> Agreed.  I like the ideas in the patches you sent, but I’m not sure
> ‘guix environment’ is the right place for them.  It goes beyond the
> typical job of ‘guix environment’.
> 
> > For example, if one of the dependencies of a program is X11, it can
> > automatically share the X paths (unless overridden by the user).  Same
> > with DBUS, sound devices, etc.  I mentioned previous ideas earlier in
> > the thread.
> 
> Indeed, that’s a good idea.  It may be good enough to pattern-match the
> store file names.
> 
> The attached version follows this suggestion:
> 
> --8<---------------cut here---------------start------------->8---
> ludo@ribbon ~/src/guix$ ./pre-inst-env guix run xdpyinfo |head
> 
> name of display:    :0.0
> version number:    11.0
> vendor string:    The X.Org Foundation
> vendor release number:    11906000
> X.Org version: 1.19.6
> maximum request size:  16777212 bytes
> motion buffer size:  256
> bitmap unit, bit order, padding:    32, LSBFirst, 32
> image byte order:    LSBFirst
> ludo@ribbon ~/src/guix$ ./pre-inst-env guix run ls -la .
> 
> total 0
> drwxr-xr-x 2 0 0 40 Jan 29 16:40 .
> drwxr-xr-x 3 0 0 60 Jan 29 16:40 ..
> --8<---------------cut here---------------end--------------->8---
> 
> For some reason IceCat and Evince crash with a GDK error, whereas GIMP
> and Xpdf are fine.
> 
> > I'd also want to integrate changes I made to `guix environment'.  If
> > people here like the changes and they are merged, I'd want to refactor
> > it into a common place, not just copy the code.
> 
> Yes, it’d be nice to have a module of utilities for environment
> management.
> 
> >            ;; container script to invoke IceCat
> >            (mkdir-p bin-dir)
> >            (call-with-output-file (string-append bin-dir "icecat-container")
> >              (lambda (port)
> >                (format port "#!/bin/bash")))
> >
> >            ;; fontconfig configuration
> >            (mkdir-p fc-dir)
> >            (call-with-output-file fc-mtg
> >              (lambda (port)
> >                (format port (string-append "<?xml version=\"1.0\"?>
> > <!DOCTYPE fontconfig SYSTEM \"fonts.dtd\">
> > <fontconfig>
> >   <dir>" (string-append (assoc-ref %build-inputs "font-dejavu")
> >                         "/share/fonts") "</dir>
> >   <cachedir>" fc-cache-dir "</cachedir>
> > </fontconfig>\n"))))
> >
> >            (setenv "PATH"
> >                    (string-append (assoc-ref %build-inputs "fontconfig")
> >                                   "/bin"))
> >            (setenv "FONTCONFIG_FILE" fc-mtg)
> >            (setenv "XDG_DATA_HOME" share-dir)
> >
> >            (mkdir-p cache-dir)
> >            (invoke "fc-cache" "-fv")))))
> 
> Nice!
> 
> Actually there are really two approaches we could use.  One is to create
> wrappers like this one that do the right thing, independently of what
> the user’s profile contains (‘guix package’ could even generate wrappers
> automatically in some cases.)
> 
> The second approach is a ‘guix run/environment’ kind of command that
> generates the environment at run time.
> 
> There are pros and cons to both, I think.
>
> Food for thought!

Interesting ideas in this thread, I just tried your last version of guix run!

Couldn't we use both? For example, we can not predict where people will store their
mail and which applications they define in the config of the mailing application
to send it and receive it (case for environment) but we can predict roughly what
will be needed for w3m to be sandboxed.

> Thanks,
> Ludo’.
> 
> 

-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

[bug#30254] [bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

Hello Mike,

There’s this last patch from the series you submitted a while back
that’s ready modulo an issue with the test.  Could you take a look?

TIA,
Ludo’.

ludo@gnu.org (Ludovic Courtès) skribis:

> Mike Gerwitz <mtg@gnu.org> skribis:
>
>> * doc/guix.texi (Invoking guix environment): Add --no-cwd.
>> * guix/scripts/environment.scm (show-help, %options): Add --no-cwd.
>> (launch-environment/container): Add 'map-cwd?' param; only add mapping for cwd
>> if #t.  Only change to cwd within container if #t, otherwise home.
>> (guix-environment): Error if --no-cwd without --container.  Provide '(not
>> no-cwd?)' to launch-environment/container as 'map-cwd?'.
>> * tests/guix-environment.sh: Add test for no-cwd.
>
> This one LGTM as well (with the test moved to
> guix-environment-container.sh).  There’s just a minor issue:
>
>> --- a/tests/guix-environment.sh
>> +++ b/tests/guix-environment.sh
>> @@ -84,6 +84,14 @@ HOME="$tmpdir" guix environment --bootstrap --container --user=foognu \
>>       --share="$tmpdir/umock" \
>>       -- guile -c "$usertest"
>>  
>> +# if not sharing CWD, chdir home
>> +(
>> +  cd "$tmpdir" \
>> +    && guix environment --bootstrap --container --no-cwd --user=foo  \
>> +            --ad-hoc guile-bootstrap --pure \
>> +            -- /bin/sh -c 'test $(pwd) == "/home/foo" -a ! -d '"$tmpdir"
>> +)
>> +
>
> This test would fail for me because my test store is at
> ~ludo/src/guix/test-tmp/store and my CWD is ~/src/guix.  So when using
> both --user and --no-cwd, the effect is that
> ~ludo/src/guix/test-tmp/store is not available at all within the
> container, and thus execve("/bin/sh") fails with ENOENT:
>
> $ ./test-env guix environment --bootstrap --container --no-cwd --user=foo --ad-hoc guile-bootstrap
> accepted connection from pid 29684, user ludo
> accepted connection from pid 29695, user ludo
> ./test-env: line 1: 29683 Terminated              "/home/ludo/src/guix/pre-inst-env" "/home/ludo/src/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
> $ echo $?
> 1
>
> Thoughts?
>
> TIA,
> Ludo’.

[bug#30254] [bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

Ludo:

On Wed, Oct 17, 2018 at 15:19:33 +0200, Ludovic Courtès wrote:
> There’s this last patch from the series you submitted a while back
> that’s ready modulo an issue with the test.  Could you take a look?

I'm not ignoring this; I'll have time to look over the next couple of
weeks.  I'll need to research the issue.

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Carl Dong]

Hi Mike and Ludo!

I believe I've found a solution to the problem that Ludo was encountering. The
reason why Ludo was having trouble was because when a user specifies `--user`,
we rewrite the targets of our filesystem mappings so that every instance of
`$HOME` (as seen ouside the container) becomes `/home/$USER`. Since this applied
to all filesystem mappings, it included our filesystem mappings for inputs too.
However, our symlinks were not updated.

My change makes it so that we _only_ update the mappings that are either
user-specified, or cwd (if applicable). This solves Ludo's problems.

Here's the patch, let me know if it looks good:
https://github.com/dongcarl/guix/compare/8e92d5465fc154fed5d06f7e4a64d7dcccded74d...2019-06-env-no-cwd-fix.patch

Cheers,
Carl Dong

[bug#30254] [bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

Hi Carl,

Carl Dong <contact@carldong.me> skribis:

> I believe I've found a solution to the problem that Ludo was encountering. The
> reason why Ludo was having trouble was because when a user specifies `--user`,
> we rewrite the targets of our filesystem mappings so that every instance of
> `$HOME` (as seen ouside the container) becomes `/home/$USER`. Since this applied
> to all filesystem mappings, it included our filesystem mappings for inputs too.
> However, our symlinks were not updated.
>
> My change makes it so that we _only_ update the mappings that are either
> user-specified, or cwd (if applicable). This solves Ludo's problems.
>
> Here's the patch, let me know if it looks good:
> https://github.com/dongcarl/guix/compare/8e92d5465fc154fed5d06f7e4a64d7dcccded74d...2019-06-env-no-cwd-fix.patch

Good catch!  The patches LGTM.  (Note: you can use the ‘Co-authored-by’
tag for the second patch, I think it’s a more or less common
convention.)

Speaking of which, could you create an account on Savannah?  That way we
could grant you commit access to make it more convenient for you and so
you can review and apply other people’s patches in your areas of expertise.

Please let me know what your account is, and reply with a message signed
by the key you’ll use to sign commits.  Also please read the ‘HACKING’
file for info on the commit “rules”.

Thanks!

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Sat, Jun 29, 2019 at 23:27:43 +0000, Carl Dong wrote:
> Hi Mike and Ludo!
>
> I believe I've found a solution to the problem that Ludo was encountering.

Thank you for picking this up, and sorry again that I wasn't able to
find the time.  I'm glad this patch is useful to someone else, and I'm
looking forward to seeing it applied.

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Carl Dong]

Hi Ludo!

> Good catch! The patches LGTM. (Note: you can use the ‘Co-authored-by’ tag for
> the second patch, I think it’s a more or less common convention.)

Done! Updated at the same link as last time:
https://github.com/dongcarl/guix/compare/8e92d5465fc154fed5d06f7e4a64d7dcccded74d...2019-06-env-no-cwd-fix.patch


> Speaking of which, could you create an account on Savannah? That way we could
> grant you commit access to make it more convenient for you and so you can
> review and apply other people’s patches in your areas of expertise.

That's super exciting! :-)

> Please let me know what your account is, and reply with a message signed by
> the key you’ll use to sign commits.

Here you go!

My fingerprint:

0401 7A2A 6D9A 0CCD C81D  8EC2 96AB 007F 1A7E D999

My signed account info:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

My Savannah account as of (Sun 07 Jul 2019 02:06:45 PM UTC) is carl.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEECc3SW1JEo3Z49u6oDMUhUxl5kaUFAl0h/I8ACgkQDMUhUxl5
kaW7tw//fxTNv+9afaC0QHoos7CQ6zhjVxyRoyGC1b9tYssXA/I/O+vEzthy2T/H
FTbJaa5YjTr09AMwKFzxp1yrGh6+yzp5YQF5uGG26N8NGTOHxet43AtMg1c7Cm7H
vG2KxQLvpUkmroc7NX+P/BZ5RruN+PJSOpssTB5PrDb3DDUzbMNTTmhWZWdEw6Er
0JIz/zH5iZhcWZZ68EILeI3OXGpgWI8D2MTrBkmgtwwL3/Z9fVDV0ui11KtSV4jK
ZTj7SJnHra9HJ6UxO47hs98oTdI1ho7cXFOBQ7GqsBwSzWBCMXaU8VsTtfGdoeMz
2EQQ0NMVOzPIeH4DHnvFLJVuTUS+0wXzmsTVvmq+NASZjZRS7H6xGjunLet/G0wQ
WqRA85tpSc6Lvr1Ab/oMRxZZnxeBQ8mJU7Y/ROe6GubdiAT5bdJBTLjeCjbARadp
UTbp+WclI0VVD/tPAcOlxJnj0iVEMBRe/hFa2o9Uvv4mZl+3NAlGKRycWXByq+l2
3Fjfqn7aF5a7R9y/itBAGh9fGUShK08Cb8/TfbTH/voX1VIzzXhAjnhBoL2p0Mi8
4l+PUZ7T7Ob5HGaz1VxztWFucXKPXZCOu9Igv1EIirTKbKzsyWZr1OGmDi8YzqHo
bD4yP39Buyoj/v/S0OE/ocGidtXx/FGGoR84yWYrx3nLtCWin+E=
=RXBz
-----END PGP SIGNATURE-----

> Also please read the ‘HACKING’ file for info on the commit “rules”.

Done!

Cheers,
Carl Dong
contact@carldong.me
"I fight for the users"

[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Ludovic Courtès]

Hello!

Carl Dong <contact@carldong.me> skribis:

>> Good catch! The patches LGTM. (Note: you can use the ‘Co-authored-by’ tag for
>> the second patch, I think it’s a more or less common convention.)
>
> Done! Updated at the same link as last time:
> https://github.com/dongcarl/guix/compare/8e92d5465fc154fed5d06f7e4a64d7dcccded74d...2019-06-env-no-cwd-fix.patch

Alright!

>> Speaking of which, could you create an account on Savannah? That way we could
>> grant you commit access to make it more convenient for you and so you can
>> review and apply other people’s patches in your areas of expertise.
>
> That's super exciting! :-)
>
>> Please let me know what your account is, and reply with a message signed by
>> the key you’ll use to sign commits.
>
> Here you go!
>
> My fingerprint:
>
> 0401 7A2A 6D9A 0CCD C81D  8EC2 96AB 007F 1A7E D999
>
> My signed account info:
>
> My Savannah account as of (Sun 07 Jul 2019 02:06:45 PM UTC) is carl.

Cool, I’ve added you to the Savannah group.  You can now push these two
patches to test it.

Thank you and welcome on board!  :-)

Ludo’.

[bug#30256] bug#30254: [PATCH 0/3] guix environment --user, --link-profile, --no-cwd

[Maxim Cournoyer]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Carl Dong <contact@carldong.me> skribis:
>
>>> Good catch! The patches LGTM. (Note: you can use the ‘Co-authored-by’ tag for
>>> the second patch, I think it’s a more or less common convention.)
>>
>> Done! Updated at the same link as last time:
>> https://github.com/dongcarl/guix/compare/8e92d5465fc154fed5d06f7e4a64d7dcccded74d...2019-06-env-no-cwd-fix.patch
>
> Alright!
>
>>> Speaking of which, could you create an account on Savannah? That way we could
>>> grant you commit access to make it more convenient for you and so you can
>>> review and apply other people’s patches in your areas of expertise.

[...]

> Cool, I’ve added you to the Savannah group.  You can now push these two
> patches to test it.

Seems the patches have indeed been pushed :-).

Closing.

Maxim