GSoC preparations

id:"20160214104030.10353.84931@thinkbox.jade-hamburg.de"

1 files changed, 14 insertions, 2 deletions

diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index bfaf330b..caaef129 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2016 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -39,10 +39,22 @@ new mechanisms.  (Translators.)  More important than the actual code is the
 documentation of what he did: he must be able to defend why he chose a certain
 approach, and explain why he believes this approach really secure.
 
-Possible mentors: Carl Fredrik Hammar (cfhammar)
+Possible mentors: Justus Winter (teythoon)
 
 Exercise: It's hard to come up with a relevant exercise, as there are so many
 possible solutions... Probably best to make an improvement to one of the
 existing translators -- if possible, something touching name resolution or and
 such, e.g. implementing file_reparent() in a translator that doesn't support it
 yet.
+
+---
+
+
+# 2016-02-14, Justus Winter
+
+I have factored out the proxying-bits from fakeroot so that it can be shared.
+The most simple chrooting translator is the identity translator, which proxies
+RPCs without really modifying them.  Combining the identity translator with
+`settrans --chroot` gives us `chroot(8)`.  With a little more work, I believe
+that can be used to implement `chroot(2)`.  Whether or not that is secure
+remains to be seen, maybe that is even an ill-conceived goal.