Merge branch 'master' into joeyconfig

2 files changed, 48 insertions, 0 deletions

diff --git a/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn b/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn
new file mode 100644
index 00000000..c4464d03
--- /dev/null
+++ b/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn
@@ -0,0 +1,25 @@
+Config snippet to reproduce:
+
+    	& Chroot.provisioned sidChroot
+      where
+    	sidChroot = Chroot.debootstrapped mempty "/tmp/sid" $ props
+    		& osDebian Unstable X86_64
+    		& User.accountFor (User "spwhitton")
+    		& userScriptProperty (User "spwhitton")
+    			[ "echo hello > /home/spwhitton/greeting" ]
+    		`assume` MadeChange
+
+During a spin, I see the error `Cannot execute /bin/sh`.
+
+I can obtain the error manually as follows.  My `/tmp` is not mounted `noexec`.
+
+    iris ~ % sudo chroot /tmp/sid /bin/bash       
+    [sudo] password for spwhitton:         
+    root@iris:/# su --shell /bin/sh -c "echo hello > /home/spwhitton/greeting" spwhitton
+    Cannot execute /bin/sh
+    root@iris:/# su --shell /bin/sh spwhitton
+    Cannot execute /bin/sh: Permission denied
+
+--spwhitton
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot/comment_1_75ae52da0638ff6ea1c04820091b89f3._comment b/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot/comment_1_75ae52da0638ff6ea1c04820091b89f3._comment
new file mode 100644
index 00000000..89bb17f1
--- /dev/null
+++ b/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot/comment_1_75ae52da0638ff6ea1c04820091b89f3._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-20T16:55:25Z"
+ content="""
+This is due to `Debootstrap.built'` removing world read access from the
+chroot it creates.
+
+So, /tmp/sid/ is not accessible by spwhitton, and when su
+has switched id to spwhitton, it can't access anything inside the chroot.
+
+See commit f6afeb889f4b11418daac7825c1adb1df4ff145c for when this was
+added. I think that the risk of farming old security vulnerabilities from
+chroots is real, but this is not a good approach for a fix.
+
+(It would work to put the chroot in a parent
+directory that is itself not world readable, then the root directory inside the
+chroot would be world readable. But this would require relocating existing
+chroots. At least when chroots are used for systemd containers,
+/var/lib/container has appropriately locked down permissions anyway.)
+
+I'm reverting that commit, and adding some permissions fixup code.
+"""]]