Subject: Re: cd into file [was: Re: CVS commit: src]
To: None <>
From: Bill Studenmund <>
List: tech-kern
Date: 08/26/2005 09:47:00
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,
> On Thu, Aug 25, 2005 at 08:22:08PM -0700, Bill Studenmund wrote:
> > > i'd rather go without mounting; then permissions, mountpoints etc get=
> > > the way for easy acceess.
> >=20
> > 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=20
> > vnodes, then auto-mouning a file system (or simple-request-to-mount) wo=
> > 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=
> :)

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=
> > 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)=

This is the first time it's become clear you are thinking about a layered=
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=
> well do the check if its a VREG and if not pass on to the lower layer. Or=
> am i overlooking things?

That would work. I think it'd be easier, though, to just mount a untarring=
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=
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=
> > it. Otherwise, I can foresee all sorts of strange issues related to the=
> > auto-expansion. Consider downloading a file. Say you started to downloa=
> > failed, and are trying to download again. You open "foo.tgz". The kerne=
> > 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 hel=
> > 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 curre=
> > file systems. I think we can solve this issue, but the main thing is th=
> > 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=
> > most file systems call panic() if they wander into the weeds. We certai=
> > 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 us=
> 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=20
> faulty disc structures only refuse to do things with it.

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

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)