From: Jeffrey L. <la...@re...> - 2007-07-12 16:34:35
|
I've been working with funionfs+FUSE to implement overlayed r/w directories on top of a readonly root filesystem. Everything works well except for one issue. Specifically, if one tries to mount a FUSE based filesystem on top of /etc you can lock the FUSE mounting process and any process which attempts to read /etc. As best as I can tell, the mount succeeds (do_mount), but fusermount hangs as soon as we try to update the mtab file (via add_mount). This can obviously be avoided by IGNORE_MTAB at compile time. However, that means that we will have no record of any FUSE mounted filesystems in /etc/mtab. What would be much better would be a "-n" option to dynamically select between updating mtab (default) or not updating mtab. That would bring FUSE-mount into line with most of the other mount programs which support a -n option. Q. From looking at lib/helper.c it appears that mounting is a multi-step process. First the filesystem is mounted, then callbacks are registered. What happens to accesses to files in the period after the filesystem has been mounted, but before the fuse_operations callbacks have been registered? Do they block (is this the possible root cause of the problem I've noted above)? If they block, is this a vector for a possible denial of service attack? Thanks, Jeff |
From: Jan E. <je...@co...> - 2007-07-12 16:44:08
|
On Jul 12 2007 10:34, Jeffrey Law wrote: > >I've been working with funionfs+FUSE to implement overlayed r/w >directories on top of a readonly root filesystem. Everything works >well except for one issue. > >Specifically, if one tries to mount a FUSE based filesystem on top >of /etc you can lock the FUSE mounting process and any process which >attempts to read /etc. > >As best as I can tell, the mount succeeds (do_mount), but fusermount >hangs as soon as we try to update the mtab file (via add_mount). > >This can obviously be avoided by IGNORE_MTAB at compile time. However, >that means that we will have no record of any FUSE mounted filesystems >in /etc/mtab. > >What would be much better would be a "-n" option to dynamically >select between updating mtab (default) or not updating mtab. That >would bring FUSE-mount into line with most of the other mount >programs which support a -n option. What would be best is, if fuse did something along the lines of... int main(...) { /* do this early */ etc_fd = open("/etc", O_DIRECTORY); } int play_with_mtab(...) { int fd = openat(etc_fd, "mtab", O_RDWR, ...); } Jan -- |
From: Jeffrey L. <la...@re...> - 2007-07-12 17:20:57
|
On Thu, 2007-07-12 at 18:43 +0200, Jan Engelhardt wrote: > On Jul 12 2007 10:34, Jeffrey Law wrote: > > > >I've been working with funionfs+FUSE to implement overlayed r/w > >directories on top of a readonly root filesystem. Everything works > >well except for one issue. > > > >Specifically, if one tries to mount a FUSE based filesystem on top > >of /etc you can lock the FUSE mounting process and any process which > >attempts to read /etc. > > > >As best as I can tell, the mount succeeds (do_mount), but fusermount > >hangs as soon as we try to update the mtab file (via add_mount). > > > >This can obviously be avoided by IGNORE_MTAB at compile time. However, > >that means that we will have no record of any FUSE mounted filesystems > >in /etc/mtab. > > > >What would be much better would be a "-n" option to dynamically > >select between updating mtab (default) or not updating mtab. That > >would bring FUSE-mount into line with most of the other mount > >programs which support a -n option. > > What would be best is, if fuse did something along the lines of... > > int main(...) > { > /* do this early */ > etc_fd = open("/etc", O_DIRECTORY); > } > > int play_with_mtab(...) > { > int fd = openat(etc_fd, "mtab", O_RDWR, ...); > } I don't really see how this helps. We don't muck with mtab until after do_mount has completed, or are you suggesting that "play_with_mtab" happen even later?. I must be missing something (not being terribly familiar with FUSE doesn't help :-) It's also not going to work well with the existing glibc API for manipulating the mtab file. They expect you to just pass in a pathname to setmntent rather than an fd or FILE * Jeff |
From: Jan E. <je...@co...> - 2007-07-12 17:25:51
|
On Jul 12 2007 11:20, Jeffrey Law wrote: >> >> What would be best is, if fuse did something along the lines of... >> >> int main(...) >> { >> /* do this early */ >> etc_fd = open("/etc", O_DIRECTORY); >> } >> >> int play_with_mtab(...) >> { >> int fd = openat(etc_fd, "mtab", O_RDWR, ...); >> } > >I don't really see how this helps. Simple: we grab an fd for the old /etc that is hidden after your custom fs overmounts /etc. >We don't muck with mtab >until after do_mount has completed, or are you suggesting >that "play_with_mtab" happen even later?. I must be missing >something (not being terribly familiar with FUSE doesn't help :-) > > >It's also not going to work well with the existing glibc API >for manipulating the mtab file. They expect you to just pass >in a pathname to setmntent rather than an fd or FILE * When using libc functions, that poses a problem, yes. If you rely on that, update mtab before mounting, and, if the mount fails, remove it again from mtab. (Rather than updating mtab too late.) Jan -- |
From: Jeffrey L. <la...@re...> - 2007-07-12 21:30:14
|
On Thu, 2007-07-12 at 19:25 +0200, Jan Engelhardt wrote: > On Jul 12 2007 11:20, Jeffrey Law wrote: > >> > >> What would be best is, if fuse did something along the lines of... > >> > >> int main(...) > >> { > >> /* do this early */ > >> etc_fd = open("/etc", O_DIRECTORY); > >> } > >> > >> int play_with_mtab(...) > >> { > >> int fd = openat(etc_fd, "mtab", O_RDWR, ...); > >> } > > > >I don't really see how this helps. > > Simple: we grab an fd for the old /etc that is hidden after > your custom fs overmounts /etc. As long as the fuse code is prepared to get an error when the entries are added to /etc/mtab -- the old /etc is readonly. > When using libc functions, that poses a problem, yes. If you rely on that, > update mtab before mounting, and, if the mount fails, remove it again from > mtab. (Rather than updating mtab too late.) I don't rely on that -- it's the fuse user-space code that relies on the glibc bits (see fusermount). And as I mentioned, we can't update the mtab before mounting because it's readonly. Jeff |
From: Goswin v. B. <bre...@in...> - 2007-07-20 09:49:24
|
Jan Engelhardt <je...@co...> writes: > On Jul 12 2007 11:20, Jeffrey Law wrote: >>> >>> What would be best is, if fuse did something along the lines of... >>> >>> int main(...) >>> { >>> /* do this early */ >>> etc_fd = open("/etc", O_DIRECTORY); >>> } >>> >>> int play_with_mtab(...) >>> { >>> int fd = openat(etc_fd, "mtab", O_RDWR, ...); >>> } >> >>I don't really see how this helps. > > Simple: we grab an fd for the old /etc that is hidden after > your custom fs overmounts /etc. You still need an -n option because the /old etc is read-only. MfG Goswin |
From: Miklos S. <mi...@sz...> - 2007-07-12 22:41:31
|
> I've been working with funionfs+FUSE to implement overlayed r/w > directories on top of a readonly root filesystem. Everything works > well except for one issue. > > Specifically, if one tries to mount a FUSE based filesystem on top > of /etc you can lock the FUSE mounting process and any process which > attempts to read /etc. > > As best as I can tell, the mount succeeds (do_mount), but fusermount > hangs as soon as we try to update the mtab file (via add_mount). > > This can obviously be avoided by IGNORE_MTAB at compile time. However, > that means that we will have no record of any FUSE mounted filesystems > in /etc/mtab. > > What would be much better would be a "-n" option to dynamically > select between updating mtab (default) or not updating mtab. That > would bring FUSE-mount into line with most of the other mount > programs which support a -n option. Yeah. > Q. From looking at lib/helper.c it appears that mounting is a > multi-step process. First the filesystem is mounted, then > callbacks are registered. > > What happens to accesses to files in the period after the > filesystem has been mounted, but before the fuse_operations > callbacks have been registered? Do they block (is this the > possible root cause of the problem I've noted above)? Yes, they block. > If they block, is this a vector for a possible denial of > service attack? Against whom? The filesystem users? Sure, but that's not just between the mount and the initialization. You can write a filesystem that does sleep(1000) in every operation. Pretty nasty DoS ;) Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-16 19:35:56
|
On Fri, 2007-07-13 at 00:41 +0200, Miklos Szeredi wrote: > > > > What would be much better would be a "-n" option to dynamically > > select between updating mtab (default) or not updating mtab. That > > would bring FUSE-mount into line with most of the other mount > > programs which support a -n option. > > Yeah. Thinking more about this, you also want the "update mtab, but don't actually do the mount" option as well that we see in other mount utilities. That way you can go back and fix mtab after issuing one or more -n mounts. > > > Q. From looking at lib/helper.c it appears that mounting is a > > multi-step process. First the filesystem is mounted, then > > callbacks are registered. > > > > What happens to accesses to files in the period after the > > filesystem has been mounted, but before the fuse_operations > > callbacks have been registered? Do they block (is this the > > possible root cause of the problem I've noted above)? > > Yes, they block. > > > If they block, is this a vector for a possible denial of > > service attack? > > Against whom? The filesystem users? Sure, but that's not just > between the mount and the initialization. You can write a filesystem > that does sleep(1000) in every operation. Pretty nasty DoS ;) Let's say that an organization is considering FUSE on a production box, but restricts the filesystems which can be mounted (don't ask me how that's done yet, it's hypothetical). So mr. badguy can't just mount any FUSE filesystem he wants, just those on the approved list. Clearly the approved list wouldn't allow the sleep (1000) DOS attack. But we've still got a vector if mr. badguy can stop the process between the mount and registering of the callbacks. Jeff |
From: Miklos S. <mi...@sz...> - 2007-07-20 09:56:12
|
> > On Jul 12 2007 11:20, Jeffrey Law wrote: > >>> > >>> What would be best is, if fuse did something along the lines of... > >>> > >>> int main(...) > >>> { > >>> /* do this early */ > >>> etc_fd = open("/etc", O_DIRECTORY); > >>> } > >>> > >>> int play_with_mtab(...) > >>> { > >>> int fd = openat(etc_fd, "mtab", O_RDWR, ...); > >>> } > >> > >>I don't really see how this helps. > > > > Simple: we grab an fd for the old /etc that is hidden after > > your custom fs overmounts /etc. > > You still need an -n option because the /old etc is read-only. Yeah, the _real_ problem is /etc/mtab. It usually works fine if you symlink /proc/mounts to /etc/mtab, but some things (like "user" mounts or automatic removal of loop devices) won't work correctly. We are working on making these corner cases work without mtab. Adding a '-n' to fuse should be fairly easy, and I can do that if the symlink thing isn't enough. Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-24 19:23:30
|
On Fri, 2007-07-20 at 11:55 +0200, Miklos Szeredi wrote: > > > > You still need an -n option because the /old etc is read-only. > > Yeah, the _real_ problem is /etc/mtab. It usually works fine if you > symlink /proc/mounts to /etc/mtab, but some things (like "user" mounts > or automatic removal of loop devices) won't work correctly. You also can't image a system using anaconda -- if you have a little %post to create the link, you'll cause severe anaconda indigestion as it wants to muck around with mtab after the %post scriptlets run. And it's not just fuse stuff that can't cope with the symlink approach. FWIW, we started with the symlink approach and eventually dumped it as not really feasible long term. > Adding a '-n' to fuse should be fairly easy, and I can do that if the > symlink thing isn't enough. That would be great. There's some further bullet-proofing that can be done (see my previous message). jeff |
From: Miklos S. <mi...@sz...> - 2007-07-20 10:01:10
|
> > Against whom? The filesystem users? Sure, but that's not just > > between the mount and the initialization. You can write a filesystem > > that does sleep(1000) in every operation. Pretty nasty DoS ;) > Let's say that an organization is considering FUSE on a production > box, but restricts the filesystems which can be mounted (don't ask > me how that's done yet, it's hypothetical). So mr. badguy can't > just mount any FUSE filesystem he wants, just those on the approved > list. Clearly the approved list wouldn't allow the sleep (1000) > DOS attack. But we've still got a vector if mr. badguy can stop > the process between the mount and registering of the callbacks. But if the user can stop the filesystem between mount and initialization, then it can stop the filesystem after the initialization as well. With the same affect. There's nothing special about the time frame between mount and initialization. Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-24 19:18:49
|
On Fri, 2007-07-20 at 12:00 +0200, Miklos Szeredi wrote: > > > Against whom? The filesystem users? Sure, but that's not just > > > between the mount and the initialization. You can write a filesystem > > > that does sleep(1000) in every operation. Pretty nasty DoS ;) > > Let's say that an organization is considering FUSE on a production > > box, but restricts the filesystems which can be mounted (don't ask > > me how that's done yet, it's hypothetical). So mr. badguy can't > > just mount any FUSE filesystem he wants, just those on the approved > > list. Clearly the approved list wouldn't allow the sleep (1000) > > DOS attack. But we've still got a vector if mr. badguy can stop > > the process between the mount and registering of the callbacks. > > But if the user can stop the filesystem between mount and > initialization, then it can stop the filesystem after the > initialization as well. With the same affect. > > There's nothing special about the time frame between mount and > initialization. OK. Thanks for the clarification. jeff |
From: Goswin v. B. <bre...@in...> - 2007-07-20 11:36:21
|
Miklos Szeredi <mi...@sz...> writes: >> > On Jul 12 2007 11:20, Jeffrey Law wrote: >> >>> >> >>> What would be best is, if fuse did something along the lines of... >> >>> >> >>> int main(...) >> >>> { >> >>> /* do this early */ >> >>> etc_fd = open("/etc", O_DIRECTORY); >> >>> } >> >>> >> >>> int play_with_mtab(...) >> >>> { >> >>> int fd = openat(etc_fd, "mtab", O_RDWR, ...); >> >>> } >> >> >> >>I don't really see how this helps. >> > >> > Simple: we grab an fd for the old /etc that is hidden after >> > your custom fs overmounts /etc. >> >> You still need an -n option because the /old etc is read-only. > > Yeah, the _real_ problem is /etc/mtab. It usually works fine if you > symlink /proc/mounts to /etc/mtab, but some things (like "user" mounts > or automatic removal of loop devices) won't work correctly. > > We are working on making these corner cases work without mtab. > > Adding a '-n' to fuse should be fairly easy, and I can do that if the > symlink thing isn't enough. > > Miklos If openat() is used then you could do a little trick. On the read-only / you add a symlink to /proc/mounts (so fusermounts does not edit mtab) and on the read-write you add an actual /etc/mtab after the mount. That way user mounts and loopback will work after bootup. MfG Goswin |
From: Jeffrey L. <la...@re...> - 2007-07-24 19:18:34
|
On Fri, 2007-07-20 at 13:36 +0200, Goswin von Brederlow wrote: > If openat() is used then you could do a little trick. On the read-only > / you add a symlink to /proc/mounts (so fusermounts does not edit > mtab) and on the read-write you add an actual /etc/mtab after the > mount. That way user mounts and loopback will work after bootup. A number of things don't work when /etc/mtab links to /proc/mounts, even if it's just for the r/o part of the root filesystem. It's not really an option. -n would solve the problem nicely, especially if we also have an option to update mtab without actually doing the mount so that we can make /etc/mtab consistent after-the-fact. This also brings FUSE into line with other mount utilities which have traditionally supplied these capabilities. Another option we could use would be to disable mucking with /etc/mtab if the initial lock attempt fails. I consider this the least desirable option. A third option would be to not muck with /etc/mtab if /etc/mtab is a child of the target mountpoint. This has the advantage of having fusermount do something sensible rather than hanging -- this is probably a good idea even if we add -n. Jeff |
From: Miklos S. <mi...@sz...> - 2007-07-24 20:24:54
|
> > > > > > You still need an -n option because the /old etc is read-only. > > > > Yeah, the _real_ problem is /etc/mtab. It usually works fine if you > > symlink /proc/mounts to /etc/mtab, but some things (like "user" mounts > > or automatic removal of loop devices) won't work correctly. > You also can't image a system using anaconda -- if you have a little > %post to create the link, you'll cause severe anaconda indigestion > as it wants to muck around with mtab after the %post scriptlets run. What is anaconda and why is it mucking with mtab? > And it's not just fuse stuff that can't cope with the symlink approach. > FWIW, we started with the symlink approach and eventually dumped it as > not really feasible long term. Interested in exactly why. I'm very much hoping the /proc/mounts approach is feasible, otherwise we are in big trouble over unprivileged mounts. Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-24 21:27:51
|
On Tue, 2007-07-24 at 22:24 +0200, Miklos Szeredi wrote: > > > > > > > > You still need an -n option because the /old etc is read-only. > > > > > > Yeah, the _real_ problem is /etc/mtab. It usually works fine if you > > > symlink /proc/mounts to /etc/mtab, but some things (like "user" mounts > > > or automatic removal of loop devices) won't work correctly. > > You also can't image a system using anaconda -- if you have a little > > %post to create the link, you'll cause severe anaconda indigestion > > as it wants to muck around with mtab after the %post scriptlets run. > > What is anaconda and why is it mucking with mtab? anaconda is the Fedora/Red Hat system installer and since it's regularly mounting/unmounting filesystems it naturally wants to keep mtab up-to-date, even in the target system. > Interested in exactly why. I'm very much hoping the /proc/mounts > approach is feasible, otherwise we are in big trouble over > unprivileged mounts. It's been a couple years since we worked with it, but IIRC the main problem was that /proc/mounts doesn't carry all the data that is found in /etc/mtab. jeff |
From: Miklos S. <mi...@sz...> - 2007-07-25 06:45:30
|
> > > > > > > > > > You still need an -n option because the /old etc is read-only. > > > > > > > > Yeah, the _real_ problem is /etc/mtab. It usually works fine if you > > > > symlink /proc/mounts to /etc/mtab, but some things (like "user" mounts > > > > or automatic removal of loop devices) won't work correctly. > > > You also can't image a system using anaconda -- if you have a little > > > %post to create the link, you'll cause severe anaconda indigestion > > > as it wants to muck around with mtab after the %post scriptlets run. > > > > What is anaconda and why is it mucking with mtab? > anaconda is the Fedora/Red Hat system installer and since it's > regularly mounting/unmounting filesystems it naturally wants > to keep mtab up-to-date, even in the target system. OK, that's during installation/upgrade. I can see that keeping mtab up to date is needed for some packages which rely on that file (although arguably that sort of dependency is not very good). But after installation, at boot time, mtab could be switched to a symlink and thinkgs should work fine afterwards. > > Interested in exactly why. I'm very much hoping the /proc/mounts > > approach is feasible, otherwise we are in big trouble over > > unprivileged mounts. > It's been a couple years since we worked with it, but IIRC the main > problem was that /proc/mounts doesn't carry all the data that is > found in /etc/mtab. Like the "loop" and "user" options. And lots of filesystems show only some or none of their mount options in /proc/mounts. Any others that you can remember? Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-25 16:48:24
|
On Wed, 2007-07-25 at 08:45 +0200, Miklos Szeredi wrote: > But after installation, at boot time, mtab could be switched to a > symlink and thinkgs should work fine afterwards. No, because the root filesystem is readonly. You don't get the chance to switch things at boot time. That's one of the "nice" things about the stuff we're working on :-) > Like the "loop" and "user" options. And lots of filesystems show only > some or none of their mount options in /proc/mounts. > > Any others that you can remember? Not offhand. jeff |
From: Miklos S. <mi...@sz...> - 2007-07-25 17:06:45
|
> > But after installation, at boot time, mtab could be switched to a > > symlink and thinkgs should work fine afterwards. > No, because the root filesystem is readonly. You don't get the > chance to switch things at boot time. That's one of the "nice" > things about the stuff we're working on :-) Then what about switching to a symlink after installation, before the reboot? I'd be so happy if this anaconda issue was the most serious one with migrating away from mtab :) Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-25 17:14:34
|
On Wed, 2007-07-25 at 19:06 +0200, Miklos Szeredi wrote: > > > But after installation, at boot time, mtab could be switched to a > > > symlink and thinkgs should work fine afterwards. > > No, because the root filesystem is readonly. You don't get the > > chance to switch things at boot time. That's one of the "nice" > > things about the stuff we're working on :-) > > Then what about switching to a symlink after installation, before the > reboot? Not really an option -- even if anaconda gets fixed, that doesn't help all the existing releases. ie, we couldn't use the stuff we're building with Fedora 7 or earlier or RHEL 5 or earlier. You can't easily go back and change DVD media.. Jeff |
From: Miklos S. <mi...@sz...> - 2007-07-25 17:18:15
|
> > > > But after installation, at boot time, mtab could be switched to a > > > > symlink and thinkgs should work fine afterwards. > > > No, because the root filesystem is readonly. You don't get the > > > chance to switch things at boot time. That's one of the "nice" > > > things about the stuff we're working on :-) > > > > Then what about switching to a symlink after installation, before the > > reboot? > Not really an option -- even if anaconda gets fixed, that doesn't help > all the existing releases. ie, we couldn't use the stuff we're building > with Fedora 7 or earlier or RHEL 5 or earlier. You can't easily go back > and change DVD media.. Sorry, I lost it there. Can you briefly describe the stuff you are building? That would probably help understadning what the problem is. Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-25 17:34:33
|
On Wed, 2007-07-25 at 19:18 +0200, Miklos Szeredi wrote: > > > > > But after installation, at boot time, mtab could be switched to a > > > > > symlink and thinkgs should work fine afterwards. > > > > No, because the root filesystem is readonly. You don't get the > > > > chance to switch things at boot time. That's one of the "nice" > > > > things about the stuff we're working on :-) > > > > > > Then what about switching to a symlink after installation, before the > > > reboot? > > Not really an option -- even if anaconda gets fixed, that doesn't help > > all the existing releases. ie, we couldn't use the stuff we're building > > with Fedora 7 or earlier or RHEL 5 or earlier. You can't easily go back > > and change DVD media.. > > Sorry, I lost it there. > > Can you briefly describe the stuff you are building? That would > probably help understadning what the problem is. Most of the details aren't that important. The key aspect is that the root filesystem is readonly and we use FUSE+funionfs to provide a writable overlay in certain parts of the root filesystem such as /etc. Other constraints are pretty simple -- we can provide new or updated packages; however we can not change the installer itself. jeff |
From: Miklos S. <mi...@sz...> - 2007-07-25 18:27:14
|
> > > > > > But after installation, at boot time, mtab could be switched to a > > > > > > symlink and thinkgs should work fine afterwards. > > > > > No, because the root filesystem is readonly. You don't get the > > > > > chance to switch things at boot time. That's one of the "nice" > > > > > things about the stuff we're working on :-) > > > > > > > > Then what about switching to a symlink after installation, before the > > > > reboot? > > > Not really an option -- even if anaconda gets fixed, that doesn't help > > > all the existing releases. ie, we couldn't use the stuff we're building > > > with Fedora 7 or earlier or RHEL 5 or earlier. You can't easily go back > > > and change DVD media.. > > > > Sorry, I lost it there. > > > > Can you briefly describe the stuff you are building? That would > > probably help understadning what the problem is. > Most of the details aren't that important. The key aspect is that > the root filesystem is readonly and we use FUSE+funionfs to provide > a writable overlay in certain parts of the root filesystem such as > /etc. OK. Actually this means, that the contents of mtab are more or less irrelevant, because it will get overwritten later during boot, after the union overlay has been mounted. At that time it could also be replaced with a symlink. I understand, that this does not help with the problem at hand: even if mtab was a symlink before the overlay is mounted, the deadlock would still happen. The only solution seems to be adding a '-n' option, but this is mostly independent of the problem of getting rid of mtab in the long term. Miklos |
From: Jeffrey L. <la...@re...> - 2007-07-25 18:48:47
|
On Wed, 2007-07-25 at 20:27 +0200, Miklos Szeredi wrote: > OK. Actually this means, that the contents of mtab are more or less > irrelevant, because it will get overwritten later during boot, after > the union overlay has been mounted. Agreed. > > At that time it could also be replaced with a symlink. If the loss of data problems were fixed, absolutely. I had in fact suggested moving to the symlink approach across the board for Red Hat internally a while back and received the pushback because the loss of data problems. > I understand, that this does not help with the problem at hand: even > if mtab was a symlink before the overlay is mounted, the deadlock > would still happen. I think so, but haven't actually tested this to be 100% sure. > The only solution seems to be adding a '-n' option, Or either of the alternatives I posted in a separate message. 1. Don't muck with mtab if you were unable to get the lock. 2. Don't muck with mtab if mtab is a child of the target mount point. I can live with any of them :-) I tend to think a -n option is wise simply to bring FUSE into line with other mount utilities and I tend to think #2 is wise as well. > but this is mostly > independent of the problem of getting rid of mtab in the long term. Agreed. I'd love to see mtab simply disappear. It's a silly piece of unix legacy that (with some work) could go away in time. jeff |