From 42fafdc21313dff0e5d1972b457d5edcc589cfb0 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 20 Nov 2016 13:22:53 -0400 Subject: Debootstap: Fix too tight permissions lock down of debootstrapped chroots, which prevented non-root users from doing anything in the chroot. --- ...perty_fails_inside_a_debootstrapped_chroot.mdwn | 2 ++ ...ent_1_75ae52da0638ff6ea1c04820091b89f3._comment | 23 ++++++++++++++++++++++ 2 files changed, 25 insertions(+) create mode 100644 doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot/comment_1_75ae52da0638ff6ea1c04820091b89f3._comment (limited to 'doc') diff --git a/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn b/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn index d42d4f79..c4464d03 100644 --- a/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn +++ b/doc/todo/userScriptProperty_fails_inside_a_debootstrapped_chroot.mdwn @@ -21,3 +21,5 @@ I can obtain the error manually as follows. My `/tmp` is not mounted `noexec`. 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. +"""]] -- cgit v1.3-2-g0d8e