> > > > If you get down to it, the thing is about delegating control over part > > > > of namespace to somebody, without letting them control, see, etc. the > > > > rest of it. So I'd rather be very conservative about extra information > > > > we allow to piggyback on that. I don't know... perhaps with stable peer > > > > group IDs it would be OK to show peer group ID by (our) vfsmount + peer > > > > group ID of master + peer group ID of nearest dominating group that has > > > > intersection with our namespace. Then we don't leak information (AFAICS), > > > > get full propagation information between our vfsmounts and cooperating > > > > tasks in different namespaces can figure the things out as much as possible > > > > without leaking 3rd-party information to either. > > > > > > > Here's a patch against current -mm implementing this (with some > > cleanups thrown in). Done some testing on it as well, it wasn't > > entirey trivial to figure out a setup, where propagation goes out of > > the namespace first, then comes back in: > > Looks nice, and a bit of testing/playing around showed no problem on my > end. Thanks for testing! Ram, how is your patch progressing? Could you send me the final version sometime, so that I can put a new version of this work together and sumbit to -mm for more eyeballs? Thanks, Miklos -- 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
