From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lutomirski Subject: Re: [REVIEW][PATCH 0/43] Completing the user namespace Date: Tue, 10 Apr 2012 18:22:41 -0700 Message-ID: References: <4F84838B.8000408@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Markus Gutschke , Will Drewry , Cyrill Gorcunov , linux-security-module@vger.kernel.org, Al Viro , linux-fsdevel@vger.kernel.org, Andrew Morton , Linus Torvalds To: "Eric W. Biederman" Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Apr 10, 2012 at 6:14 PM, Eric W. Biederman wrote: > Andrew Lutomirski writes: > >> On Tue, Apr 10, 2012 at 6:01 PM, Eric W. Biederman >> wrote: > >> Sounds like you're reinventing (something very similar to) >> no_new_privs. =A0Why not just require no_new_privs as a prerequisite= for >> creating a user namespace if you're unprivileged? > > As I said in the part of my email you snipped, because no_new_privs w= ill > break suid exec in the user namespace. > > I am most definitely not going to require something that will make > implementing/using user namespaces almost pointless. This part: > Currently the suid exec will fail because the uid's don't map. > > I might switch that around to simply ignoring the change of uid > on suid exec. I have a patch in my devel tree that plays with > that idea. However as much as I hit that case once in testing > (I think it was ping). I don't think running suid executables > is particularly interesting. I'm totally lost now. I'll wait until I play around with the patches s= ome more. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html