From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: bind mount that lies to apps about st_uid? Date: Wed, 15 Jul 2015 10:53:30 +1000 Message-ID: <20150715005330.GS3902@dastard> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kenton Varda , "Eric W. Biederman" , Drew Fisher , David Renshaw , linux-fsdevel@vger.kernel.org To: Andrew Lutomirski Return-path: Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:16718 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbbGOAxo (ORCPT ); Tue, 14 Jul 2015 20:53:44 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jul 14, 2015 at 05:41:01PM -0700, Andrew Lutomirski wrote: > On Tue, Jul 14, 2015 at 5:35 PM, Kenton Varda wrote: > > Hi Eric, > > > > I'm curious to know if you think this the following is something that could > > realistically be implemented, or if it's a totally outrageous idea. :) > > > > For Sandstorm, we've found a case where it would be useful if we could > > create a bind-mount in which stat() calls lie and claim all files have UID > > 65534 (as if their real owner wasn't mapped into the user namespace). All > > actual security checks would behave normally; only the result of stat() > > would be affected. > > > > Specifically, the problem is that some apps have checks of the form: "If > > file is owned by my UID, then modify it, otherwise do something else > > reasonable." These checks are wrong in the case of read-only bind mounts, > > but legacy code rarely considers such a possibility. > > > > Making maters worse, it is the case currently that some configurations of > > Sandstorm will have these read-only files owned by the UID running the app > > while others will not. Thus this is an observable difference between servers > > that can affect app behavior, causing them to work fine on some servers but > > break on others, which is something we want to avoid at all costs. We can't > > see any reasonable way to resolve the difference without kernel help, > > unfortunately. > > > > So, it would be convenient if I could trick these apps into behaving > > correctly by asking the kernel to lie to them about the UID. For our use > > case, a boolean flag would work. It could simply say: "For stat() purposes > > on this mount, act as if the uid_map and gid_map are empty, therefore return > > st_uid and st_gid as 65534." Alternatively, I'd also be happy with a "uid=" > > setting that overrides all reported UIDs, which seems possibly more broadly > > useful, but also possibly riskier(?). I'm also happy with restricting this > > to only mounts with MS_RDONLY and MS_NOSUID, if that helps. > > > > It's a hack, but it's simple and would save a bunch of confusion for our > > developers in the long run, I think. Why wouldn't you just use an ld preload library to intercept stat() calls in userspace and manipulate them there? No kernel changes required, no app changes required.... Cheers, Dave. -- Dave Chinner david@fromorbit.com