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

  • Done
  • quality assurance status badge
Details
5 participants
  • Carl Dong
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mike Gerwitz
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Mike Gerwitz
Severity
normal
Merged with
M
M
Mike Gerwitz wrote on 26 Jan 2018 04:29
(address . guix-patches@gnu.org)
7bc71eaa3cff48ec7dc0d4fe406dde9482b716a9.1516937216.git.mtg@gnu.org
* 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(-)

Toggle diff (133 lines)
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJaaqCpAAoJEIyRe39dxRui3kwP/j/g7RtKUhxxh/6OMocxf4KR
+4wO+THWCS/eG23gGsEUAQ9llz56BFGBRF0SR2Cz/ldQafUAUmND27ZXjfA/li2M
rCBTLnW65NiMJi8YPMGwaVkDvGoN9GDKpsJYQDxISWLNKn7Mb9Cpdjvesop5aE1d
mWYK9K3dafGdUyh+gefCo9aXM/6nHURfwHRbQUsw3i+duQkeqBnE+QSjDjhEY6EU
vQk0sBVmgrcCyIBsKcCOo3LL++QggZTUa7n+3KQp9mcIb1ruPu8XMZw4gEfLAZaV
Qm0pS6CZYy9dX5g8w1Qbh0jenYFeA93QdSA60vPdfx7SUZgVS08BbIV0b+Svr6yu
fumyhmFWAAOyMCoYR3ZPBoydqBEQ+0U3ny1O0HIHzshkGOqLQCcbbW98xGNObZLI
TCyiBnCMPDPtzyMJ/X8Xet7jrQIF9tfXnXzOCha+uAK2vd8VLl+DIggtb3bImQ/i
XE693bTzu+5KVIVeC1Rapup06Vg3GsvdZNFz4QLHy/TTvMrJCF2YKtYDiCZCOMck
LV9qA8ZSh4okc11FQqmaGWJ7VA4Pj97wlMm2y16o6gYXt86SSQf9ET69MadawlXP
otqpje3AnLpUv4o3Ubvh0RVRiEbW1LRO9swY0fWCbfyq18EtXUE6ARrmANxlZNG0
nKQwafK4qe7JoxCEn5lc
=UKN6
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 2 Mar 2018 11:54
(name . Mike Gerwitz)(address . mtg@gnu.org)(address . 30256@debbugs.gnu.org)
87tvtyhhnd.fsf@gnu.org
Mike Gerwitz <mtg@gnu.org> skribis:

Toggle quote (8 lines)
> * 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:

Toggle quote (15 lines)
> --- 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:

Toggle snippet (8 lines)
$ ./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’.
M
M
Mike Gerwitz wrote on 2 Mar 2018 19:00
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30256@debbugs.gnu.org)
877equgxx7.fsf@gnu.org
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:
Toggle quote (30 lines)
>> --- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJamZFFAAoJEIyRe39dxRuiRkkQAIqrzkOPRrupZM0e2+w8B207
2Yyd8Fh4kFnis7FBpDJ9kz+FOiD3mpWYzfmCFQr/Z7CrPYVevnNXqS9sYtibKeNu
laV9dHt9LtBtWAfmwLu+DAqpOD/SCGZn8fRhWJNBwvYmq+Ojqi2PvLfhsQlXStWL
XB4ccwkCd4H+Y9JxXetT3pLQw1xLDAHnphTshU9DQ+E4qfnA5uX/wclwMzwhuYT/
kFvP40fvXVrZMLieAaQNGFNnBfiQy4/iyoOCNWVkSZYUXXflzmROuTkXePxdTtXv
JRsOzgVrdQMZoxFhyuwOB+XSq4S9Q1MVE8jeZGZ2ndyx1LLLYlsm8xtcr1W2wG4B
xq573Sqn+vvciwhAaRYt9pTIAAPYY2eMJz55rI0TysNbgzwlfJJABqtaytn4NmTL
heBEAGPcjmDcWwMkfFz001jA64NuhS0oJMcq2TZ+Zlh8+OqBwO0Ywua1R+8BoprI
BRmfJwdTcIAvo1PSPnTcMSLeOBK5s69Y74ibAQlGVxlHpLeCVjC+O3SnuauYNGMg
UewzSKOUD0kZ7xePy1Oia0K2VfmNVAH91FivfFvlK2st9gpNVqwj1vT7SQhC2SaG
WtMeFA2++ZEnGdpZRg5OjWId9cn1BoJRQHBWfLlq1mBVWA7b+AvEhJgc24DNhz/c
gDSoXDkj+c00/ZRtx6CB
=JVGH
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 3 Mar 2018 15:44
(name . Mike Gerwitz)(address . mtg@gnu.org)(address . 30256@debbugs.gnu.org)
87zi3p9q1w.fsf@gnu.org
Hi Mike,

Mike Gerwitz <mtg@gnu.org> skribis:

Toggle quote (5 lines)
> 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!

Toggle quote (3 lines)
> 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. :-)

Toggle quote (4 lines)
> 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!

Toggle quote (5 lines)
> 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’.
L
L
Ludovic Courtès wrote on 3 Mar 2018 22:22
control message for bug #30256
(address . control@debbugs.gnu.org)
87efl0am80.fsf@gnu.org
merge 30256 30254
M
M
Mike Gerwitz wrote on 4 Mar 2018 19:03
Re: [bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30256@debbugs.gnu.org)
87y3j7btwp.fsf@gnu.org
On Sat, Mar 03, 2018 at 15:44:43 +0100, Ludovic Courtès wrote:
Toggle quote (12 lines)
>> 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.

Toggle quote (10 lines)
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJanDTWAAoJEIyRe39dxRuiNIIQAKoy54MoU3wZHNFAHV+GTOCd
SqBikep+B/ER0QAfnF5UodTdAmEQRXV3E5n5MtKuf7erjWRrKuz6x5Bt8mujIFQV
bXMDACJCgM3OGLsR/H8paFRcf0o/mTE2sRCTIF/8ayrZHhm1+7v68yOLZYTTJHaa
BHtM1hq6TxAtgdKNspZzkIDEmI35J9oJWbybgPQaBY30mG4nyObDzH1f0JeB31HS
wlwH2oZjdVOCVHBz7lmqZAE4VIEr1bAfB7WUDSxKxNLcFlkPii+Qd3i/tw0TjENV
SLt/OgVYrrrzkywEgOXLB5r4WOeLr/7Mh44pEVI0OntVLABP0ejw+0PoQgu2ZT6+
I5QCpAgnq845bZsb70NRtrxGqyYLDHxcdj63ut9KePJhWDQESGtvoqmD8tMzKFvd
LYN0zYtZg6pxi/mebf5pNF5xcN/bclXE8tYIdAP9W4AALB7D6VQZ5wF2HpR8hdnB
FBVHWJcQW6g4BnJtMEXaqPAj+xr+t01G6SMurW0oax0DN/BHR1VWVKE1ZCc0Oo4u
283QQPVmj6e1CQLtA/+f/0lmjsh6T0Xdun5mbRSjg/4NCpEgRZDLIQG/aWf0OrKc
axr0L2rhaJ3Pk766ZdyRlfmhqJDsHh8684xzwjycOCuDvvlzKipeHiu6p0KnQzg1
EuJ3qqqzoqYtCHnc208e
=iXGu
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 4 Mar 2018 23:24
(name . Mike Gerwitz)(address . mtg@gnu.org)(address . 30256@debbugs.gnu.org)
87tvtv32ec.fsf@gnu.org
Heya,

Mike Gerwitz <mtg@gnu.org> skribis:

Toggle quote (2 lines)
> On Sat, Mar 03, 2018 at 15:44:43 +0100, Ludovic Courtès wrote:

[...]

Toggle quote (15 lines)
>> 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.

Toggle quote (4 lines)
> 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’.
M
M
Mike Gerwitz wrote on 5 Mar 2018 19:03
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30256@debbugs.gnu.org)
87d10ibds4.fsf@gnu.org
On Sun, Mar 04, 2018 at 23:24:27 +0100, Ludovic Courtès wrote:
Toggle quote (4 lines)
> 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!

Toggle quote (8 lines)
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJanYZ8AAoJEIyRe39dxRuiv8MP/10bVlqnBbPkk99zpHZODV+v
zK/Q/gfv+aXIMzRUC34H/fVfiy2qeyqBeEmPIvOmJRMYQQjMsPaJKiWl3nPCxofd
BhKSZmkGc7eEHqFxPUOXWeaS9oKAN4bR31TisPteyQzq2nCaXeynnhntI3Uwnc8n
TqjfXO0OMYmXpQAgD4MnOvot84ZJI8sNyd8wiKbrSdThLBsAj49qXrCMRBX67nZ3
aefOQYzcIQknB6ZI+/EcFPV+Hlemswf4fFFUNXJ8aXVzNxY4F4NPQdzdX1mkj1b0
WCeoltkdkQrslNJoE/f5fI+891qpwj0R1ruLXsljasWFxA56MKEwnyGSW+vkJUwb
UUhzHvokJVisiPqk3Qe0ZuIdef3xjigxoriQ/3uW0/NjITbI+MZaWL2rYidP/RWs
QDljkSr2rXbtb6SfZDa+f3PRWB2SYkAG4Y8tORBaaV/g7pbDQim8FVm2GcD/fo/4
sk7VFISeLlT9FWp/8T3NTIdTLHIcpHPob6ZhfH/L6E3LuVFde49V/77xDrXsDulx
sCAh0GtTgMvSK4V7ZQiW+3UKuC7t6kNDqR/V73celO3TvYwVUw8cGgEzEAfwsXKe
R6DasyI65kRt/lJNIf0SoW0FJZBJhs5c7q5WJl7lRTdOVq7GlmmfQkkFIF/eQrSE
qLS6tM8lqvYw4UKRxjwZ
=cVDi
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 6 Mar 2018 11:20
(name . Mike Gerwitz)(address . mtg@gnu.org)(address . 30256@debbugs.gnu.org)
878tb5zes8.fsf@gnu.org
Hello,

Mike Gerwitz <mtg@gnu.org> skribis:

Toggle quote (2 lines)
> On Sun, Mar 04, 2018 at 23:24:27 +0100, Ludovic Courtès wrote:

[...]

Toggle quote (14 lines)
>> 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.

Toggle quote (11 lines)
> 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.

Toggle quote (8 lines)
> 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’.
M
M
Mike Gerwitz wrote on 6 Mar 2018 19:07
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30256@debbugs.gnu.org)
87efkx84cn.fsf@gnu.org
On Tue, Mar 06, 2018 at 11:20:23 +0100, Ludovic Courtès wrote:
Toggle quote (16 lines)
> 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.

Toggle quote (11 lines)
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJantj5AAoJEIyRe39dxRuiflEQAKYItQrmMaqSrzQG40iELks9
623kK0dFwe/49HHdEDs7qye2u0uSigDrMDR/xMivOFDdbvZ6z+7Jmlg5E0Dhrex6
SSJoQTCKmXcitPRnUXqeVsaj2VN8bcaMxVdzTixxtwHtEKKGfm/503k9K2RxB9o7
1aMgYTMHZPHN8vhCT2EZ4Us1x8RR8TXyjNUpjo989NvoQJxqz33fPjjgUMjrQZE+
aKzCTNKyMrVoU6lzuMsilMvavQ2wfBKv+Z1qOHTo9UDCwvurQe4rAwaUQ+NK0vyH
peyiHWFsh7hd9e18hv4GmGWY9kLfclE8guX/tHPmRWElIClkREezpIbGqT7gYdLE
17SZhe1wPORZT5WDEASikYsWVBvFDZRWy2hxP41Xe8K1LaFbwJf+zAcGkxWaJd0F
OuLtdOFopWpnNRmiZwzxdkWLaEU+UCoNU5jI2Z/WKenE7+gkikaJkuWlqiB6C1+F
XLzwhaQrf2JMzF29Iyg6Z6vDZ03t1aAlTNYCjFZIwupAYY+SXh+YZRkQuChOOx8X
gV4WZXg3PidPCZLpol508kXt9KwQPbmp+5qZJaz9rvhNP4Zw2ZoCRPFHUIWHg5Zt
lzz1Pt+axRT2Z+sBMmeGiGMeXbMwiS0JYbJNfITj2IKu08xM2yA0A+DrYs66+KfP
Gzl0uOYdRxXVcup3oiNy
=6Kf3
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 17 Oct 2018 14:19
(name . Mike Gerwitz)(address . mtg@gnu.org)
87murcdaui.fsf@gnu.org
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:

Toggle quote (45 lines)
> 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’.
M
M
Mike Gerwitz wrote on 8 Nov 2018 02:56
(name . Ludovic Courtès)(address . ludo@gnu.org)
87lg64xrfx.fsf@gnu.org
Ludo:

On Wed, Oct 17, 2018 at 15:19:33 +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJb45fSAAoJEIyRe39dxRuisEMQALzkRSbdn1DLakjTK2vMJTMh
oNJI00NgVPrmTbCgohtIZCvW9rhdmhgDmWr3gSM1I+3ptMKoN79kQCcT3O/seKWd
1oh1MOswwwzNaZPBuVqq8m8FjE25OmYm4+FAT+KJWV3xBA2t3gUuxWway4OLmL7w
wFkMTWUftScog0Aa2BceI56dXT6YmheajMoTjhhc27lnAT71Yf3qPsNfjs7VpGjY
Wqz6oC7h3Kv44WNN7KbUV0Zilvfh/zpU8AKeayovd9v4gQUudiCtPEimPi9VPeuZ
pvQk412DOfTAZYSCai8y8+2JYsXks+BGXd1+yX/cOqHp7tvAcrDxna96X0H1DS4d
+O1srjpEhsb39HvCnya/u6c7ltWNjUAdojksm2KpY5eMjQkvkhV5O6K/0wAZf53l
9jyd4uJ9hLYqKlspbiTvFCAqa3SDp43/deKT3PR1Gd7x04c7R+GtF9PLwvIOSsVY
ZUlsujv/YWQqGVt9LJ0XN2ffQ+wyZ8xxIyPQBtnRUHNFlJrOIXxtkuRKdVuSDB4g
kZPky1QyBhG9HldJEDyvr3JXeyDxgPGBxpAt0K3vadv+5fL59+7Q59oaSnKkC2ln
FpXEw+8cz+93Xjh8N3zybBl9sGfh+LVp87Cjd06Dlw+g/bcCsCoRGV165VHa3kuy
bAe5pEu9SpGWVxBcicgv
=V7Ay
-----END PGP SIGNATURE-----

R
R
Ricardo Wurmus wrote on 4 Feb 2019 14:29
control message for bug #30254
(address . control@debbugs.gnu.org)
168b8b31ef3.2c1a096-1530070560.2547737053220808969@zoho.com
tags 30254 moreinfo
C
C
Carl Dong wrote on 30 Jun 2019 01:27
Re: [bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.
(name . 30256@debbugs.gnu.org)(address . 30256@debbugs.gnu.org)
JDVMtiOOy1lDfdtXZ_gejE0CTwO2En_Gr9J7SqXB0-5RDJzBaCN91gsXgyT7c9Vsd27TlZvDYrYOpwcxYX93JgkM2IILUCLq8p3ahIId21k=@carldong.me
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:

Cheers,
Carl Dong
L
L
Ludovic Courtès wrote on 7 Jul 2019 15:18
(name . Carl Dong)(address . contact@carldong.me)
87lfxac7ab.fsf@gnu.org
Hi Carl,

Carl Dong <contact@carldong.me> skribis:

Toggle quote (13 lines)
> 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’.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEPORkVYqE/cadtAz7CQsRmT2a67UFAl0h8RwACgkQCQsRmT2a
67Xc+Q/+Kq8VHJSSLVX8lMtbCNz+PR7fjFXVIou2E81SyQ1RzjeK/Iy0RbwdsOnX
02/GB1+8WK2F4L/j+48DEAzNO9Pg3AMYNITXaCyhxx0uqjhCIgWK5XBfLnjgGGIO
e2U2mxRhwCDAK5hbdlJncrtax6rgqouZmUiPkTfJ6cnJRmYAWtl/2zKf7aPxiZ/Z
k9k2E4IUcsDrP/tpl6CT8WUiFOBvzudfbFij3PH7a17kzO7TQKJAK7R9R2LdywwC
teZ2BYzpqF+eMo1+L13aQpC+Kh58rYDU+DWsIVtm0vnEJqLdkiOZsgIMOlIhuluN
gS1RR06af/ayJsxilwS3DUjXKetVo0Dr7EaOyhSzW0UfYepHZQVQDDVu9ELJ2qu5
QaWZGcWqx+tS78JHIO3yHgWisTaB473JroKPJbvCkoDMTXrHoyEoRA9kX4IzPL5N
DT+8GcXhn+iAQneZBBxemRZuxVlEMi3lqP5NMLH9bsS7Gm2hCFKCqYoBEGKhgLiQ
qEDTJLVrT96f39KxItPrps40qrvPWu3U8vcxf9XIlIHM8yZ1PC44UTViH8aKmq+r
YhD+RjsiyYNq2frW7U+Nv7INkyHWujmMFhmhw2rfv9cfU00+Eq/yIqu2dR3B4PiS
Ubz0hngpdNh1ySpgoJq0Cgj5hyrcHd6nWsVwhda/rawJp83RWFg=
=SlEi
-----END PGP SIGNATURE-----

M
M
Mike Gerwitz wrote on 7 Jul 2019 15:45
(name . Carl Dong)(address . contact@carldong.me)(name . 30256@debbugs.gnu.org)(address . 30256@debbugs.gnu.org)
87zhlqt0ul.fsf@gnu.org
On Sat, Jun 29, 2019 at 23:27:43 +0000, Carl Dong wrote:
Toggle quote (4 lines)
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJdIfdyAAoJEIyRe39dxRuiREkP/jTzOmbh5nwphZ+lpGKFEl2z
nRCgBvUYpKEXVIrjb0cj2J3dIWQlaNH05b5WMWrNMNZ2yIE7al7g0oyI5eg+LTHZ
Pm2clIHzhxobjEOcp2ksIV0QIe9lnivpplhbsfScr9SZjrdWZGswMfSL6L+LaD+x
oPlMNx968hWYCBajjVihHfYumyLNaQmNlD25cThI7SREl1F9WZKpsF4yZdt6gksS
8XJFdJWuLLMIizCnDtRyCj8kNNMVeyTqCCftSkIOVAGpPfrMXJ7LKelzmTul/U8F
VeuohjR5t01PItXZD5BEeTRryiO1+FMh2egX791zbTnFtCqA3aHYZ6FK5SR0eI+T
BrbOQE+Q+uk1sPaAVz4m+2+1RYtFDJ1TQLsfuQFRa7tw/YA2hCdLk9zTRicrTJAu
DLEbbIUDQqQfJ1NJJeSj2XXQMnSJ8r3lreEFuCWAEQ/o0wwdbTaPSho6+tPt8L7p
lYi3hd/Q5nhGW2RmqA3XGgT7OgKH8qK9bCgBYike18cKaWIT9wWCa0I5tD1iPbiH
jOvOchhZb/hhNbAsZhvFlY+yoKu5jFfL5RzHDb5ilVfMO1F1ZHYeUk3bAybJ7Wr1
5GSR0QgQNijWbyAcpcAEthN8jfh9XdE6TugAo2pPWfgZ4VzidS/f33dC5fIiLVKY
5TYNihTK5MWjcxQCOWs7
=yx4h
-----END PGP SIGNATURE-----

C
C
Carl Dong wrote on 7 Jul 2019 16:24
(name . Ludovic Courtès)(address . ludo@gnu.org)
vCDSvqheChD-h05S3NXhAuMvyL4U2OfbdM0jiniLAw_V2KSaHAJFa4u9WPkZ4zjgYuzedT0UxRDw9_17QVELk1j07bj0CzSvSZT5Lw8pKA4=@carldong.me
Hi Ludo!

Toggle quote (3 lines)
> 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.)

Toggle quote (4 lines)
> 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! :-)

Toggle quote (3 lines)
> 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-----

Toggle quote (2 lines)
> Also please read the ‘HACKING’ file for info on the commit “rules”.

Done!

Cheers,
Carl Dong
contact@carldong.me
"I fight for the users"
L
L
Ludovic Courtès wrote on 8 Jul 2019 11:41
(name . Carl Dong)(address . contact@carldong.me)
87pnmkhnhv.fsf@gnu.org
Hello!

Carl Dong <contact@carldong.me> skribis:

Toggle quote (6 lines)
>> 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!

Toggle quote (19 lines)
>> 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’.
M
M
Maxim Cournoyer wrote on 14 Jul 2021 15:18
Re: bug#30254: [PATCH 0/3] guix environment --user, --link-profile, --no-cwd
(name . Ludovic Courtès)(address . ludo@gnu.org)
875yxdowy4.fsf_-_@gmail.com
Hello,

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

Toggle quote (16 lines)
> 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.

[...]

Toggle quote (3 lines)
> 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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 30256@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 30256
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch