Subject: Re: cd into file [was: Re: CVS commit: src]
To: Bill Studenmund <wrstuden@netbsd.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 08/26/2005 17:08:27
--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--