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. There was some talk at LSF/MM about more generally allowing remapping of the view of uids. This would probably be a per-superblock thing instead of a per-mount-point thing, but some kind of remapping per mount point seems like a sensible thing to me. Eric, thoughts? --Andy -- 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
