--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2005 at 05:08:27PM +0200, Reinoud Zandijk wrote:
> Hiya Bill,
>=20
> 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=20
> > > the way for easy acceess.
> >=20
> > How do mountpoints get in the way? I can see how permissions could, but=
=20
> > once we tackle the issue of turning a user-supplied file into kernel=20
> > vnodes, then auto-mouning a file system (or simple-request-to-mount) wo=
n't=20
> > be a problem.
>=20
> for one, one has to have several `spare' mountpoints around for mounting=
=20
> the archives on; a ~/mountpoints/* could help :) but not my preferred way=
=20
> :)

Huh? Just mount the uncompressing file system on the file of the archive.

> > 1) Big issue is that if we aren't using mount points, then the "ustarfs=
"=20
> > has to be wedged into each file system. So we have to teach "ustarfs"=
=20
> > to ffs, and lfs, and ext2fs, and msdosfs, and hfs (soon), and ntfs, and=
=20
> > nfs, and afs, and coda, and cd9660fs, and anything else we have.
>=20
> why would that be? if you layer the (lets call it `archivemount' for now)=
 =20

This is the first time it's become clear you are thinking about a layered=
=20
file system.

> filesystem on top of the normal filesystem like syncfs does all=20
> VOP_LOOKUP() calls will first pass trough this `archivemount' FS and this=
=20
> well do the check if its a VREG and if not pass on to the lower layer. Or=
=20
> am i overlooking things?

That would work. I think it'd be easier, though, to just mount a untarring=
=20
file system on the file.

My main concern is that for every "real" file and directory, we now need=20
two vnodes (one below, one above). But the only vnodes that matter are the=
=20
ones on regular files that are archives. Say they represent 5% of the=20
files in a file system (which I think is on the high side). We now have=20
double-vnodes on the vast majority of the file system for no gain.

> > 2) If you want the tarfs or whatever mounted, you should have to ask fo=
r=20
> > it. Otherwise, I can foresee all sorts of strange issues related to the=
=20
> > auto-expansion. Consider downloading a file. Say you started to downloa=
d,=20
> > failed, and are trying to download again. You open "foo.tgz". The kerne=
l=20
> > notices it's a .tgz and mounts tarfs on top. The kernel hopefully copes=
=20
> > with a partial download. You then go to write the new download. All hel=
l=20
> > breaks lose, or you can't download.
>=20
> good point. see below.
>=20
> > 3) Any such file system will have to be much more robust than our curre=
nt
> > file systems. I think we can solve this issue, but the main thing is th=
at
> > 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 no=
w,=20
> > most file systems call panic() if they wander into the weeds. We certai=
nly
> > don't want it to be easy for a user archive to do that. :-)
>=20
> also good point. A validator would be nessisary yes.
>=20
> I wonder if in the current code a MSDOS floppy or CD9660 disc could be us=
ed=20
> for attacks; am allmost tempted to try. In my userland UDF implementation=
=20
> i've been pretty carefull for semi-corrupt discs and it won't panic on=20
> faulty disc structures only refuse to do things with it.

Attacks on the kernel? Certainly could happen. That is why we usually only=
=20
let root mount things. The 4.4BSD option to let users mount things was=20
nice, but opens up too many vulnerabilities.

Take care,

Bill

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDD0eDWz+3JHUci9cRAqLGAKCI3UzBn/XWE5llptx6L9qSSXPTCgCeNkF2
UGq89zrNjiATU+52Ap4JbJc=
=rU+/
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--