sahlberg
commented
8 years ago On Mon, Nov 14, 2016 at 12:28 PM, Julian Hjortshoj <notifications@github.com
wrote:
We've been looking into the possibility of using fuse-nfs with the uid/gid flags in order to set the effective user for a mount to be different from the currently running user. What we've found is that it doesn't work very well unless the currently running user is root.
The reason is that while it works fine for write operations--the file owner information is sent as the specified arbitrary uid/gid, for list/stat operations, the uid/gid is not translated back to the uid of the running user.
So, if as a non-root user, I mount a volume with some other uid/gid: fuse-nfs -n "nfs://127.0.0.1/export/share1?uid=2000&gid=2000" -m ./mymount2
I can write new files to the volume, but then, because the client OS doesn't think the resulting files are owned by the current user, I cannot edit them:
vcap@vagrant-ubuntu-trusty-64:/home/vagrant/mymount2$ echo "strange" > strangeness vcap@vagrant-ubuntu-trusty-64:/home/vagrant/mymount2$ cat strangeness strange vcap@vagrant-ubuntu-trusty-64:/home/vagrant/mymount2$ echo "strange" >> strangeness bash: strangeness: Permission denied vcap@vagrant-ubuntu-trusty-64:/home/vagrant/mymount2$ cat strangeness strange
We found that we can resolve this by just adding a check to fuse_nfs_getattr() to test if the file is owned by the UID set in the mount URL, and set the current user UID into stbuf instead, but we are wondering if this is really a bug, or if we are just misunderstanding the intent of putting UID and GID in as options to begin with.
Good analysis. This sounds like a bug.
The uid and gid arguments were originally meant for to cope with native windows builds of the nfs library as well as make it work under aros. I never really gave it much thought when it came to being used via fuse-nfs.
I think you are largely correct in that the right fix is probably to add remapping to the stat function. This remapping should be conditional and only happen iff uid/gid arguments are present in the url.
But I think this is the right thing to do. Can you send me a pull request with this change so that you get proper credit for the fix?
( Btw, I never expected many/any real use of this module as almost all systems have nfs clients in the kernel anyway, mind if I ask what your use-case for fuse-nfs is? )
regards ronnie sahlberg
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sahlberg/fuse-nfs/issues/6, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeNkKDGQcgqO6jI5IY9l8f-84aIGTkOks5q-MR8gaJpZM4KxxYd .
lwoydziak
julian-hj
We've been looking into the possibility of using fuse-nfs with the uid/gid flags in order to set the effective user for a mount to be different from the currently running user. What we've found is that it doesn't work very well unless the currently running user is root.
The reason is that while it works fine for write operations--the file owner information is sent as the specified arbitrary uid/gid, for list/stat operations, the uid/gid is not translated back to the uid of the running user.
So, if as a non-root user, I mount a volume with some other uid/gid:
fuse-nfs -n "nfs://127.0.0.1/export/share1?uid=2000&gid=2000" -m ./mymount2I can write new files to the volume, but then, because the client OS doesn't think the resulting files are owned by the current user, I cannot edit them:
We found that we can resolve this by just adding a check to
fuse_nfs_getattr()to test if the file is owned by the UID set in the mount URL, and set the current user UID intostbufinstead, but we are wondering if this is really a bug, or if we are just misunderstanding the intent of putting UID and GID in as options to begin with.