stat() of mountpoint

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

stat() of mountpoint

Nikolaus Rath
Hello,

It seems to me that if --allow-root is not used, root can not only
(correctly) not access the mounted filesystem, but he also cannot
stat() the mountpoint.

I think this is a bit strange, because if I can open a directory then
I should be able to stat() everything that is returned by readdir(),
shouldn't I?


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Miklos Szeredi
On Mon, 17 Nov 2008, Nikolaus Rath wrote:
> It seems to me that if --allow-root is not used, root can not only
> (correctly) not access the mounted filesystem, but he also cannot
> stat() the mountpoint.

Yes.  The reason is that fuse cannot query the userspace filesystem
for the attributes of the filesystem root, because that way the
filesystem could block the progress of root process.

We could return made-up attributes, if this was really important.  But
programs seem to handle this case fairly well.  Other than the strange
error message on 'ls', there doesn't seem to be anything going bad
because of this.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:

> On Mon, 17 Nov 2008, Nikolaus Rath wrote:
>> It seems to me that if --allow-root is not used, root can not only
>> (correctly) not access the mounted filesystem, but he also cannot
>> stat() the mountpoint.
>
> Yes.  The reason is that fuse cannot query the userspace filesystem
> for the attributes of the filesystem root, because that way the
> filesystem could block the progress of root process.
>
> We could return made-up attributes, if this was really important.
> But programs seem to handle this case fairly well. Other than the
> strange error message on 'ls', there doesn't seem to be anything
> going bad because of this.

Yes, but strange error messages popping in the logs can be quite an
annoyance, even more so if they result in non-zero exit codes.

Here is an example of the problems that arise from this:

I regularly back up /home/* with storeBackup. Since there is a fuse
mounted .gvfs in the home directories, root is not able to access it.
Hence I have added an exclude rule for /home/*/.gvfs and expected
everything to work fine. However, storeBackup apparently relies on the
fact that it can stat() stuff returned by readdir(), so the
excludeRule is only applied *afterwards*. Therefore storeBackup still
tries to stat() the .gvfs, which gives a very unexpected error
(permission denied rather than 'file not found' which is handled
because it could happen if the file has been deleted after the
readdir() call).

I would believe that similar problems arise with many other backup
programs, because the assumption that one can stat() everything in a
directorywith at worst getting a "file not found" seems very
reasonable.


Therefore I'd argue in favor of returning something useful. IMO root
should at least be able to find out that the entry corresponds to a
directory. So what about returning the properties of the original
directory, before it became a mountpoint?

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Ron Yorston
Nikolaus Rath <[hidden email]> wrote:
>I would believe that similar problems arise with many other backup
>programs, because the assumption that one can stat() everything in a
>directorywith at worst getting a "file not found" seems very
>reasonable.

Indeed, I had problems using rsync to back up /home after Gnome introduced
the ~/.gvfs mountpoint.

>Therefore I'd argue in favor of returning something useful. IMO root
>should at least be able to find out that the entry corresponds to a
>directory. So what about returning the properties of the original
>directory, before it became a mountpoint?

Agreed, just pretending that the directory is empty would solve the
problem.

Ron

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Miklos Szeredi
In reply to this post by Nikolaus Rath
On Tue, 18 Nov 2008, Nikolaus Rath wrote:

> Here is an example of the problems that arise from this:
>
> I regularly back up /home/* with storeBackup. Since there is a fuse
> mounted .gvfs in the home directories, root is not able to access it.
> Hence I have added an exclude rule for /home/*/.gvfs and expected
> everything to work fine. However, storeBackup apparently relies on the
> fact that it can stat() stuff returned by readdir(), so the
> excludeRule is only applied *afterwards*. Therefore storeBackup still
> tries to stat() the .gvfs, which gives a very unexpected error
> (permission denied rather than 'file not found' which is handled
> because it could happen if the file has been deleted after the
> readdir() call).
>
> I would believe that similar problems arise with many other backup
> programs, because the assumption that one can stat() everything in a
> directorywith at worst getting a "file not found" seems very
> reasonable.
>
>
> Therefore I'd argue in favor of returning something useful. IMO root
> should at least be able to find out that the entry corresponds to a
> directory. So what about returning the properties of the original
> directory, before it became a mountpoint?

mkdir /tmp/a
chown foo /tmp/a
chmod 777 /tmp/a
mkdir /tmp/b
chown bar /tmp/b
chmod 444 /tmp/b
fusefs /tmp/a
mount --bind /tmp/a /tmp/b

now the same filesystem is mounted over both /tmp/a and /tmp/b.  What
should stat return?  (NB. the filesystem doesn't know which path it
was accessed through)

So no, this doesn't work.  We can return a zero permission for both:

d--------- 2 owner group 0 1970-01-01 a

This would work, but it's still an ugly hack, because it means that we
return different attributes depending on the user ID of the process
asking.

The nice solution is private namespaces, it _is_ possible to set them
up, but not trivial.  And unfortunately distros are not yet forced
into implementing this.  Maybe the pain with ~/.gvfs vs. backups will
do that ;)

Want to become early testers?  There's a pam module that does some of
this private namespace stuff, but last I looked it was hopelessly
buggy.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:

> On Tue, 18 Nov 2008, Nikolaus Rath wrote:
>> Here is an example of the problems that arise from this:
>>
>> I regularly back up /home/* with storeBackup. Since there is a fuse
>> mounted .gvfs in the home directories, root is not able to access it.
>> Hence I have added an exclude rule for /home/*/.gvfs and expected
>> everything to work fine. However, storeBackup apparently relies on the
>> fact that it can stat() stuff returned by readdir(), so the
>> excludeRule is only applied *afterwards*. Therefore storeBackup still
>> tries to stat() the .gvfs, which gives a very unexpected error
>> (permission denied rather than 'file not found' which is handled
>> because it could happen if the file has been deleted after the
>> readdir() call).
>>
>> I would believe that similar problems arise with many other backup
>> programs, because the assumption that one can stat() everything in a
>> directorywith at worst getting a "file not found" seems very
>> reasonable.
>>
>>
>> Therefore I'd argue in favor of returning something useful. IMO root
>> should at least be able to find out that the entry corresponds to a
>> directory. So what about returning the properties of the original
>> directory, before it became a mountpoint?
>
> mkdir /tmp/a
> chown foo /tmp/a
> chmod 777 /tmp/a
> mkdir /tmp/b
> chown bar /tmp/b
> chmod 444 /tmp/b
> fusefs /tmp/a
> mount --bind /tmp/a /tmp/b
>
> now the same filesystem is mounted over both /tmp/a and /tmp/b.  What
> should stat return?  (NB. the filesystem doesn't know which path it
> was accessed through)

Yeah, I know it's not a perfect solution. But I think it's better than
the current behaviour.

> So no, this doesn't work.  We can return a zero permission for both:

That'd be fine with me as well.

>
> d--------- 2 owner group 0 1970-01-01 a
>
> This would work, but it's still an ugly hack, because it means that
> we return different attributes depending on the user ID of the
> process asking.

Why would that be necessary? Can't we always return 0700 with uid of
the user that invoiced fuse?

> The nice solution is private namespaces, it _is_ possible to set
> them up, but not trivial. And unfortunately distros are not yet
> forced into implementing this. Maybe the pain with ~/.gvfs vs.
> backups will do that ;)
>
> Want to become early testers? There's a pam module that does some of
> this private namespace stuff, but last I looked it was hopelessly
> buggy.

Could you explain roughly what private namespaces are and how they
would help?

Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Miklos Szeredi
On Wed, 19 Nov 2008, Nikolaus Rath wrote:

> Miklos Szeredi <[hidden email]> writes:
> >
> > d--------- 2 owner group 0 1970-01-01 a
> >
> > This would work, but it's still an ugly hack, because it means that
> > we return different attributes depending on the user ID of the
> > process asking.
>
> Why would that be necessary? Can't we always return 0700 with uid of
> the user that invoiced fuse?

What about the other attributes?  Modification time, size or number of
hard links?  It's impossible to make those up without asking the
filesystem.

> > The nice solution is private namespaces, it _is_ possible to set
> > them up, but not trivial. And unfortunately distros are not yet
> > forced into implementing this. Maybe the pain with ~/.gvfs vs.
> > backups will do that ;)
> >
> > Want to become early testers? There's a pam module that does some of
> > this private namespace stuff, but last I looked it was hopelessly
> > buggy.
>
> Could you explain roughly what private namespaces are and how they
> would help?

Best to try it out, attaching a little program that will run a shell
in a new mount namespace.  Try mounting and umounting in the private
namespace and see how it affects the original namespace.

Miklos

----
/* newns.c */
#include <stdio.h>
#include <unistd.h>
#include <sched.h>
#include <sys/wait.h>

int childfn(void *p)
{
        (void) p;
        execl("/bin/bash", "/bin/bash", NULL);
        perror("Cannot exec bash");
        return 1;
}

int main(void)
{
        char buf[10000];
        pid_t pid, p;

        pid = clone(childfn, buf + 5000, CLONE_NEWNS | SIGCHLD, NULL);
        if ((int) pid == -1) {
                perror("clone");
                return 1;
        }
        p = waitpid(pid, NULL, 0);
        if (p == (pid_t) -1) {
                perror("waitpid");
                return 1;
        }
        return 0;
}

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Nikolaus Rath
Miklos Szeredi <[hidden email]> writes:

> On Wed, 19 Nov 2008, Nikolaus Rath wrote:
>> Miklos Szeredi <[hidden email]> writes:
>> >
>> > d--------- 2 owner group 0 1970-01-01 a
>> >
>> > This would work, but it's still an ugly hack, because it means that
>> > we return different attributes depending on the user ID of the
>> > process asking.
>>
>> Why would that be necessary? Can't we always return 0700 with uid of
>> the user that invoiced fuse?
>
> What about the other attributes?  Modification time, size or number of
> hard links?  It's impossible to make those up without asking the
> filesystem.

Yes, certainly. But actually my question was why these attributes
depend on the asking process.


   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Nikolaus Rath
In reply to this post by Miklos Szeredi
Miklos Szeredi <[hidden email]> writes:
> Best to try it out, attaching a little program that will run a shell
> in a new mount namespace.  Try mounting and umounting in the private
> namespace and see how it affects the original namespace.

Not much:

[0] nokile:~$ newns
clone: Operation not permitted
 

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Ron Yorston
In reply to this post by Miklos Szeredi
Miklos Szeredi <[hidden email]> wrote:

>On Wed, 19 Nov 2008, Nikolaus Rath wrote:
>> Miklos Szeredi <[hidden email]> writes:
>> >
>> > d--------- 2 owner group 0 1970-01-01 a
>> >
>> > This would work, but it's still an ugly hack, because it means that
>> > we return different attributes depending on the user ID of the
>> > process asking.
>>
>> Why would that be necessary? Can't we always return 0700 with uid of
>> the user that invoiced fuse?
>
>What about the other attributes?  Modification time, size or number of
>hard links?  It's impossible to make those up without asking the
>filesystem.

Suppose I'm a sysadmin who wants to take a backup of a filesystem that
might contain mounted FUSE filesystems.  Currently my backup software
may fail in unexpected ways because the backup process can see that a
directory exists but can't access it.

I'd like my backup to succeed and I'd like it to contain the mountpoint
with the ownership and permissions that it would have if it wasn't
being used as a FUSE mountpoint.  Then if I have to restore from the
backup the mountpoint is correctly reinstated.

I don't want to backup whatever the user happens to have mounted, and I
could live with not backing up files that were in the mountpoint before
the user performed their FUSE mount.  If those files were important
they shouldn't have hidden them by mounting over the directory.

So, I'd like to have my backup process see an active FUSE mountpoint as
having the ownership and permissions of the underlying directory, but
as being empty.

Ron

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Miklos Szeredi
On Thu, 20 Nov 2008, Ron Yorston wrote:

> Miklos Szeredi <[hidden email]> wrote:
> >On Wed, 19 Nov 2008, Nikolaus Rath wrote:
> >> Miklos Szeredi <[hidden email]> writes:
> >> >
> >> > d--------- 2 owner group 0 1970-01-01 a
> >> >
> >> > This would work, but it's still an ugly hack, because it means that
> >> > we return different attributes depending on the user ID of the
> >> > process asking.
> >>
> >> Why would that be necessary? Can't we always return 0700 with uid of
> >> the user that invoiced fuse?
> >
> >What about the other attributes?  Modification time, size or number of
> >hard links?  It's impossible to make those up without asking the
> >filesystem.
>
> Suppose I'm a sysadmin who wants to take a backup of a filesystem that
> might contain mounted FUSE filesystems.  Currently my backup software
> may fail in unexpected ways because the backup process can see that a
> directory exists but can't access it.

Right.

> I'd like my backup to succeed and I'd like it to contain the mountpoint
> with the ownership and permissions that it would have if it wasn't
> being used as a FUSE mountpoint.  Then if I have to restore from the
> backup the mountpoint is correctly reinstated.

Yes.

> I don't want to backup whatever the user happens to have mounted, and I
> could live with not backing up files that were in the mountpoint before
> the user performed their FUSE mount.  If those files were important
> they shouldn't have hidden them by mounting over the directory.
>
> So, I'd like to have my backup process see an active FUSE mountpoint as
> having the ownership and permissions of the underlying directory, but
> as being empty.

Yes, I think we all agree, that this is the goal.  The only problem is
how to actually implement it.  This is something that has been
discussed at length in various forums, and we are pretty much in
agreement that the only proper solution is with private namespaces.

And now most of the infrastructure in kernel needed for this is ready,
all we have to do is implement and test the userspace part.  And this
is something perhaps you can help with.

Thanks,
Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Miklos Szeredi
In reply to this post by Nikolaus Rath
On Wed, 19 Nov 2008, Nikolaus Rath wrote:

> Miklos Szeredi <[hidden email]> writes:
> > On Wed, 19 Nov 2008, Nikolaus Rath wrote:
> >> Miklos Szeredi <[hidden email]> writes:
> >> >
> >> > d--------- 2 owner group 0 1970-01-01 a
> >> >
> >> > This would work, but it's still an ugly hack, because it means that
> >> > we return different attributes depending on the user ID of the
> >> > process asking.
> >>
> >> Why would that be necessary? Can't we always return 0700 with uid of
> >> the user that invoiced fuse?
> >
> > What about the other attributes?  Modification time, size or number of
> > hard links?  It's impossible to make those up without asking the
> > filesystem.
>
> Yes, certainly. But actually my question was why these attributes
> depend on the asking process.

Because for the non-owner the query to the userspace filesystem cannot
go out: it would make it possible for a broken or malicios filesystem
to block the halt the progress of the backup program for example.

We could return the cached attributes to non-owner queries, but what
if the attributes haven't yet been queried at all?

Sure, something could be done, that's probably halfway sane most of
the time, but still this wouldn't be a proper solution.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Miklos Szeredi
In reply to this post by Nikolaus Rath
On Wed, 19 Nov 2008, Nikolaus Rath wrote:
> Miklos Szeredi <[hidden email]> writes:
> > Best to try it out, attaching a little program that will run a shell
> > in a new mount namespace.  Try mounting and umounting in the private
> > namespace and see how it affects the original namespace.
>
> Not much:
>
> [0] nokile:~$ newns
> clone: Operation not permitted

Need to run it as root.

Miklos

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Jonathan Pryor
In reply to this post by Ron Yorston
On Thu, 2008-11-20 at 10:23 +0000, Ron Yorston wrote:
> Suppose I'm a sysadmin who wants to take a backup of a filesystem that
> might contain mounted FUSE filesystems.  Currently my backup software
> may fail in unexpected ways because the backup process can see that a
> directory exists but can't access it.

Surely you could replace "FUSE filesystems" with, say NFS filesystems in
which the NFS daemon is misbehaving, thus hanging your backup process...

In which case you really don't want a FUSE-specific solution, you want a
general solution, e.g. rsync(1)'s `rsync -x` option, which restricts the
file/directory traversal to only one filesystem, thus preventing it from
hitting FUSE filesystems, NFS filesystems, and localfilesystems that
happen to be mounted or symlinked under the directory you're backing up.

Sure, it's not ideal -- you may want to backup some of those nested
filesystems -- but it's a general, already existing solution.

 - Jon



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: stat() of mountpoint

Nikolaus Rath
Jonathan Pryor <[hidden email]> writes:
> On Thu, 2008-11-20 at 10:23 +0000, Ron Yorston wrote:
>> Suppose I'm a sysadmin who wants to take a backup of a filesystem that
>> might contain mounted FUSE filesystems.  Currently my backup software
>> may fail in unexpected ways because the backup process can see that a
>> directory exists but can't access it.
>
> Surely you could replace "FUSE filesystems" with, say NFS filesystems in
> which the NFS daemon is misbehaving, thus hanging your backup process...

As far as I know, FUSE is the only filesystem that can be mounted by
users (and on arbitrary mountpoints). So I don't think the case of an
NFS (or anything else) mountpoint suddenly popping up in /home/* is
realistic.

> In which case you really don't want a FUSE-specific solution, you want a
> general solution, e.g. rsync(1)'s `rsync -x` option, which restricts the
> file/directory traversal to only one filesystem, thus preventing it from
> hitting FUSE filesystems, NFS filesystems, and localfilesystems that
> happen to be mounted or symlinked under the directory you're backing up.

That is certainly true, but not a solution to the problem with FUSE.
I'm pretty confident that there is a number of programs that still
stat() the mountpoints and only process filesystem restrictions
afterwards. The readdir()+stat() idiom is just too common.


Best,


   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel