On Tue, Jul 14, 2015 at 05:41:01PM -0700, Andrew Lutomirski wrote: > On Tue, Jul 14, 2015 at 5:35 PM, Kenton Varda <kenton@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
