linux filesystem kernel module/chrooting/xfs/etc.

Neulinger, Nathan R. nneul at umr.edu
Tue Apr 25 22:34:23 CEST 2000


This isn't really applicable to this list, but I didn't get anywhere with
linux-kernel - that's all too concerned with bleeding edge 2.3 stuff,
nothing that is worth anything for stuff _NOW_.

Given your guys familiarity with the filesystem development, I thought I'd
ask here.

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.

The purpose of this would be to:  chdir, chroot, setuid  in a particular
executable (ftpd, smbd, cgiwrap/httpd) such that the resulting process would
APPEAR to be in a normal filesystem - i.e. directory paths will not have
changed any (/users is still /users), but only that uid's (and a selected
set of data) would be available.

I figure - worst case scenario, I could hack arlad to route all requests on
a pseudo/xfs filesystem through a user space daemon that would filter and
scan a directory elsewhere - but this seems like it would be very
innefficient. However, I'm willing to go that route as a last resort.

What I would do there is create the chroot area, populate it with the
minimal amount of stuff, and then mount my fakefs-arlad on
"/chroot-area/users". 

What I was wondering is:

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

	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?

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

	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?

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

-- Nathan

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





More information about the Arla-drinkers mailing list