--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hiya Bill,

On Thu, Aug 25, 2005 at 08:22:08PM -0700, Bill Studenmund wrote:
> > i'd rather go without mounting; then permissions, mountpoints etc get in 
> > the way for easy acceess.
> 
> How do mountpoints get in the way? I can see how permissions could, but 
> once we tackle the issue of turning a user-supplied file into kernel 
> vnodes, then auto-mouning a file system (or simple-request-to-mount) won't 
> be a problem.

for one, one has to have several `spare' mountpoints around for mounting 
the archives on; a ~/mountpoints/* could help :) but not my preferred way 
:)

> > Propably a VOP_LOOKUP `overload' like syncfs and friends could, when asked 
> > for VOP_LOOKUP of a name on a VREG file, check for common archive formats 
> > and automatically insert ustarfs or whatever its called.
> > 
> > Idea?
> 
> I don't like it. :-)
> 
> 1) Big issue is that if we aren't using mount points, then the "ustarfs" 
> has to be wedged into each file system. So we have to teach "ustarfs" 
> to ffs, and lfs, and ext2fs, and msdosfs, and hfs (soon), and ntfs, and 
> nfs, and afs, and coda, and cd9660fs, and anything else we have.

why would that be? if you layer the (lets call it `archivemount' for now)  
filesystem on top of the normal filesystem like syncfs does all 
VOP_LOOKUP() calls will first pass trough this `archivemount' FS and this 
well do the check if its a VREG and if not pass on to the lower layer. Or 
am i overlooking things?

> 2) If you want the tarfs or whatever mounted, you should have to ask for 
> it. Otherwise, I can foresee all sorts of strange issues related to the 
> auto-expansion. Consider downloading a file. Say you started to download, 
> failed, and are trying to download again. You open "foo.tgz". The kernel 
> notices it's a .tgz and mounts tarfs on top. The kernel hopefully copes 
> with a partial download. You then go to write the new download. All hell 
> breaks lose, or you can't download.

good point. see below.

> 3) Any such file system will have to be much more robust than our current
> file systems. I think we can solve this issue, but the main thing is that
> we will now readily be permitting user data to be turned into kernel
> structures. So mal-formed archives could be a huge DOS attack. Right now, 
> most file systems call panic() if they wander into the weeds. We certainly
> don't want it to be easy for a user archive to do that. :-)

also good point. A validator would be nessisary yes.

I wonder if in the current code a MSDOS floppy or CD9660 disc could be used 
for attacks; am allmost tempted to try. In my userland UDF implementation 
i've been pretty carefull for semi-corrupt discs and it won't panic on 
faulty disc structures only refuse to do things with it.

Cheers,
Reinoud


--gBBFr7Ir9EOA20Yy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQw8wZIKcNwBDyKpoAQL6lwgAozbvmdmeeLrcXkHrsOH98tfWLU8IflYI
3vEaBcKiOU35N4C7gwzlavlklD/CJGVktkVE4Gb95BzIBsRfx24aaxBBIMaiXT9e
u/650ZFJtdHDAusKp2oxrnbA0QGrB8Cnu2wCFMcw71aYzOj12xucjs5+OnvQ5q5U
H/eMW/HxkvKAQBbLNbOqOKEdrkYZQ6k1SZY6gKwPofgMOK6snynAunPVZMytY3Pb
oe+bxb3f93h5E87UNJwYnL+jKMwYF4dssuq5S/ccqSdpAADomDcdknkAvXp6XhrT
xK+llsraAlAp88TjU9hJmyNM01IlZRtjNG0iONsD43V8I25ZB4FJDA==
=zTlk
-----END PGP SIGNATURE-----

--gBBFr7Ir9EOA20Yy--