On Wed, 2008-03-05 at 20:34 +0100, Miklos Szeredi wrote:
quoted text
> > > > > 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


quoted text
> 
> Thanks,
> Miklos

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html