On Mon, Apr 03, 2000 at 08:14:12AM -0500, Neulinger, Nathan R. wrote:
> I'm not sure I understand the relevance here...
>
> My primary goal was to have a filesystem mount that could appear to contain
> different files/dirs for each process. The files/dirs it contains would
> really be mappings back to the real filesystem.
That's what namespaces are for. Different views on the resource 'filesystem' for
different processes.
> Now, if you're meaning that someone could do something like take the 'bind'
> type mount support from those patches and modify it into doing what I was
> wanting - that's a possibility worth looking at. I think I might even be
> willing to take the approach of having the mount directly display the full
> contents of the mapped directory (i.e. show all user directories) but remap
> the permissions so that regardless of what the perms are in reality, it
> appears to only be 700 in the chrooted area.
Mapping permissions would AFAIK be relative easy when namespace will go into linux ...
> The key component is how to get the fs to indicate that "when accessing this
> file, you really are accessing this other dir", but without making the
> mounts.
Hmm, what's the problem with mount -t bind ?
> One approach that might be possible to take would be to modify autofs - but
> the problem with that is that I don't want to see the machine with hundreds
> of mounts... that can't possibly be efficient. The other problem is - that
> once the dir is mounted, it will be accessible to all users using that
> chrooted area.
Yep. Once more namespaces are the solution.
Christoph
-- Always remember that you are unique. Just like everyone else.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:10 EST