On Wed, 2008-03-05 at 20:34 +0100, Miklos Szeredi wrote: > > > > > 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? Miklos, sorry. will have it your way tonight. Or the latest by the end of the week. RP > > 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