linux filesystem kernel module/chrooting/xfs/etc.

[Nathan Neulinger]

Assar Westerlund wrote:
> 
> "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.

Thanks. Comments within...

> > 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.

The problem then is that you have to either chroot it such that all of
/users is accessible, or you have to have a separate chroot location for
every userid, with the corresponding thousands of mounts of the real
data area and the user home dirs.

> >       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.

How does this handle the situation where the permissions on parent
directories later change? Is there a cache-invalidation operation that
takes place on all files/dirs nested underneath that parent, or is it
simply a matter that since there is no "open a file by inode" operation,
the user would not have any way of identifying the file. 

> >       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.

Well, sortof. I don't want different operations on _files_, just on
directories. The basic idea is, I want to have a chrooted area where
users (thousands of them) have a limited set of tools (enough for CGI),
and the ability to access their own home directory only, i.e. /users
would be the specialized mount that only showed them subdirs that were
owned by them. This chrooted area would be shared by all users. 

For various reasons, taking away all world read rights or setting all
dirs to the same group would cause problems. 

I suppose a really simple approach would be to have my fakefs-arlad
simply handle the /users directory only and have it strip away all
group/other perms before returning the directory, and return 111 perms
for the /users directory itself, which would prevent listing any
files/dirs. 

It's also possible that I could do a really simple modification to
autofs to do this. I believe the latest autofs has the ability to create
tree's of directories. I'll have to look into that. It might actually be
alot simpler. 

> 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.

I thought about this possibility. But I figured that the time to make
the mounts would be excessively slow. It may be worth a try though. It
also has the slight negative that you have to make certain all those
mounts are cleaned up when you're done. 

There's also the negative that this might create hundreds of mounts on
the machine at times. I'm not sure how much of an impact this would have
on filesystem traversals for all other operations.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul at umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216