Andrew Lutomirski <andy@xxxxxxx> writes: > 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. Remapping the ids on a filesystem to the ids in the system on a superblock basis is comparatively straight forward and something that is necessary to allow unprivileged users to mount filesystems that have any kind of storage. Basically all that would require is having a user namespace parameter on the superblock. Once overlayfs is handled that will probably give your the per mount flexibility you dream of. As to the original question of remapping ids only in stat. I agree with Dave Chinner use LD_PRELOAD. Maintaining kernel code is costly and that is a hack I don't want to maintain for the rest of eternity it appears to have entirely too little value. Eric -- 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
