linux filesystem kernel module/chrooting/xfs/etc.

[Assar Westerlund]

"Neulinger, Nathan R." <nneul at umr.edu> writes:
> Given your guys familiarity with the filesystem development, I thought I'd
> ask here.

Sure, ask ahead.  I'll take a try at answering the easy questions.

> Basically, what I'd like to do is a specialized chroot filesystem that can
> be shared amongst many users, but only certain portions of that filesystem
> would be visible to certain userids. 
> 
> I.e. our normal filesystem looks like this:
> 
> 	/bin...
> 	/usr...
> 	/users/userid/
> 	/products...
> 	/etc
> 	...
> 
> I would like to create a directory structure containing the minimal
> componets of the above directories, and have /users be treated specially,
> such that any access into /users will only allow the process to see
> directories that are owned by itself.

I think that should try to approach this problem differently.
Can you instead create a tree and mount the stuff that you want there?
If you just mount the appropriate user's home directory, you would get
the same effect, wouldn't you?  Does it have to be the same chrooted
directory that's used by all users.

> 	1. When a directory is read in a filesystem, is that directories
> data shared between all processes (i.e. like the block cache), or is it only
> accessible by the particular process that read it.

It's shared.

And this assumption, that the same file is the same for all users is
also in xfs/Arla.  So it a file is cached, it's given out to all users
that ask for it (assuming they have the right to read it).  You could
of course, make it so that other users have no rights on the same
file, but then you would not get much benefit from the caching.

Or, you could have separate file systems, and therefore probably
separate xfs/arlad for different users.

> The reason for this question - if I have the fakefs-arlad return a
> particular listing of subdirectories, that listing will depend on
> what the UID of the accessing process is. If it's shared, I've
> accomplished nothing, since eventually, a lot of the user's
> directories will have been accessed.

Yes, I think this is a problem.

> 	Related to this - if a directory listing is returned, and the
> contents of that directory is returned differently in another process - does
> this screw things up for the first process or are they completely
> independent?

See above, since they would be shared, this could produce strange effects.

> 	2. Is there any way to return something to xfs, or do something
> withing XFS that says something like "to get beneath this directory, you
> really need to access some path on this other filesystem". There is some
> sort of loopback mount support in 2.3 I believe (not sure if it's in 2.2)
> but from what I've heard, it's broken (.. doesn't behave properly). 

Not really.  XFS is just a poor little slave that hands out whatever
bits the daemon tells it.  You could implement `loopback' mounts by
having the daemon fetch the files from some other real directory.

> 	3. If I go to adapt arla's arlad/xfs implementation for this
> purpose, is there a way you can suggest that I implement it so as to more
> peacefully co-exist with arla? Such as is there some way to have it use
> /dev/xfs1 instead of /dev/xfs0 or something like that?

Yes, you can use /dev/xfs1.  There's nothing stopping you from having
a large number of minor devices but for one small constant.

> 	4. Lastly, am I insane? :) Is there some other way of doing this
> that I'm missing?

I don't think what you're trying to do here fits the Unix model very
well.  In Unix, basically it's the file identities that matter, and
not so much the agent that tries to access them.  Either you can do an
operation on a file or you cannot.  There have been some Unix-systems
that have had variant symlinks, which could for example point to
different points (@sys in AFS is also somewhat like this).  But you
would totally different behaviour for different users, which is
different.

Would it work for you to build chroot-ed trees on demand?  So that
ftpd or something does create and populate a tree when the user has
logged in.  I think this would be much simpler.

/assar