Desired result:
chrooting users for running cgi,ftp,etc.
Problem:
chrooting ftp implies a change to the user's home dir, "cd
/home/userid" won't work any more
chrooting cgi implies you have to have a full perl/etc. tree for every
user or hokey loopback mounts (which really isn't suitable for thousands
of users)
Idea:
create a special filesystem module that functions similar to autofs,
but on a per-uid basis
What I was thinking is something like:
directory structure at /usr/local/chroot-base
user home dirs /home ==> /usr/local/chroot-base/home
insmod remapfs.o
mount -o realroot=/home -t remapfs none /usr/local/chroot-base/home
run app/whatever chrooted to /usr/local/chroot-base
Now, whenever a file access occurs to "/" on the remapfs, it looks at
the uid of the process doing the access and the file/dir that is
attempting to be accessed, such as the dir 'fred'. It will then look at
the real /home/fred and see if that userid is the owner, if it is, it
will somehow cause all further accesses by that process to access the
real /home/fred instead.
This has numerous benefits - for one, from the user perspective - they
can't even tell they are chrooted - it looks to them like nothing has
changed - this means you could chroot ANY service and the users would
never be impacted.
This is similar to autofs, but autofs doesn't distinguish between
processes/userids, once a fs is mapped, it's mapped for all users, what
I'm looking for is a virtual fs mount that has a different meaning
depending on what uid is accessing through the mount.
Is what I'm thinking about above possible? I can think of an
implementation using the arla xfs module and a replacement for arlad -
basically do all the translation using a user-space helper daemon, but
it seems like that might be really inneficient. One way would be to have
the arlad replacement (remapd) actually handle ALL file/dir accesses,
the other approach would be to somehow have remapd return a pointer to
another filesystem's inode if such a thing is possible. The latter would
almost certainly be more efficient, but would have to do something weird
at the top level to prevent ".." from traversing out of the chrooted
area.
If anyone has any suggestions/thoughts/etc. I'd appreciate the input.
Please cc to me, as I'm only watching kerneltraffic.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@umr.edu
University of Missouri - Rolla Phone: (573) 341-4841
CIS - Systems Programming Fax: (573) 341-4216
-
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:08 EST