Christopher R. Hertel
crh at nts.umn.edu
Mon Mar 26 21:58:37 GMT 2001
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi Jeremy,
> I like Chris's idea of a 'wrapper' fs.
Thanks. Some thoughts...
A wrapper fs would be a per-OS implementation because each OS would have a
different set of underlying filesystems and different OS conventions for
implementing filesystems. ick.
On the other hand... I have seen one interesting wrapper OS
implementation that worked well enough (I think). The goal, in this case,
was to create an encrypted filesystem.
If memory serves, they did this by mounting a normal filesystem at a
hidden mount point (something like /.hiddenfs/fs01) and then using a
small, specialized NFS daemon to "serve" the hidden filesystem. The NFS
filesystem was then mounted at the "real" mount point.
In this case, things we would want to do would be:
- Ensure that only the daemon and/or root could read/write the 'hidden'
filesystem, if possible. Note that on bootup the hidden filesystem
could still be fsck'd, etc. That's good.
- NFS was used because it was something the OS knew how to mount. That
makes it easy. We might need to do the same since not all OSes know
how to mount SMB.
- The server would handle all of the ACL database management.
- The server would only provide limited services via the loopback address.
This ensures that outsiders cannot get to the hidden filesystem itself.
(At least, I hope it does.) It should probably only allow one
connection at a time.
These are just wild thoughts. I don't know what kind of speed bump this
would impose and I have no idea if NFS can handle the ACLs in the first
place. If not, then another mechanism would need to be found, but the
general architecture is probably in there somewhere.
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz
More information about the samba-technical