On Wed, 2005-04-20 at 10:09, Al Viro wrote: > On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote: > > Reading through the thread I assume the requirement is: > > > > 1) A User being able to create his own VFS-mount environment > > 2) being able to use the same VFS-mount environment from > > multiple login sessions. > > 3) Being able to switch some processes to some other > > VFS-mount environment. > > Excuse me, but could somebody give coherent rationale for such requirements? > _Especially_ for joining existing group by completely unrelated process - > something we don't do for any other component of process.
Would it be wrong to do (3) if access-controlled properly? Currently the only way to share the same namespace is to inherit it, which is possible only if the process belongs to the heridity chain of the creator of the namespace. I extracted the requirement (3) from this discussion -------------------------------------------------------------------- > We think namespaces are a nice way to do that: making a user-owned > filesystem only visible to a user. But the mechanism of CLONE_NEWNS > does not work, because it presumes namespace divisions are only > propagated over parent-child divisions, like environment variables. > What we really want is a mount point that propagates across all the > processes owned by one user, but is not there for other users. This is almost certainly bogus. Same user can easily want several different environments set on the same box. -------------------------------------------------------------------- RP > - > 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 - 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
