> > I wonder, what is wrong in reporting mounts in other namespaces that > > either receive and send propagation to mounts in our namespace? > > A plenty. E.g. if foo trusts control over /var/blah to bar, it's not > obvious that foo has any business knowing if bar gets it from somebody > else in turn. And I'm not sure that bar has any business knowing that > foo has the damn thing attached in five places instead of just one, > let alone _where_ it has been attached. > > 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.
This sounds fine. I'll have a look at implementing a stable peer group ID (it doesn't need a separate object, I realized that now). Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
