Quoting Miklos Szeredi (miklos@xxxxxxxxxx): > > So then as far as you're concerned, the patches which were in -mm will > > remain unchanged? > > Basically yes. I've merged the update patch, which was not yet added > to -mm, did some cosmetic code changes, and updated the patch headers. > > There's one open point, that I think we haven't really explored, and > that is the propagation semantics. I think you had the idea, that a > propagated mount should inherit ownership from the parent into which > it was propagated. Don't think that was me. I stayed out of those early discussions because I wasn't comfortable guessing at the proper semantics yet. But really, I, as admin, have to set up both propagation and user mounts for a particular subtree, so why would I *not* want user mounts to be propagated? So, in my own situation, I have done make / rshared mount --bind /share /share make /share unbindable for u in $users; do mount --rbind / /share/$u/root make /share/$u/root rslave make /share/$u/root rshared mount --bind -o user=$u /share/$u/root/home/$u /share/$u/root/home/$u done All users get chrooted into /share/$USER/root, some also get their own namespace. Clearly if a user in a new namespace does mount --bind -o user=me ~/somedir ~/otherdir then logs out, and logs back in, I want the ~/otherdir in the new namespace (and the one in the 'init' namespace) to also be owned by 'me'. > That sounds good if everyone agrees? I've shown where I think propagating the mount owner is useful. Can you detail a scenario where doing so would be bad? Then we can work toward semantics that make sense... -serge - 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
