Closed GoogleCodeExporter closed 9 years ago
1. What exactly do you mean by 'change permissions of a remote share for
"anyone" to 0'?
2. What exactly do you mean by '"active" user on the file system'?
3. What's your definition of a root-only file system?
4. What's your definition of FUSE? MacFUSE follows the FUSE API for the most
part, but not everything is, or
can be identical across Linux and Mac OS X. MacFUSE is a completely different
implementation and permission
handling in particular differs from that on Linux (also because of the
underlying platform differences).
Original comment by si...@gmail.com
on 12 Jul 2007 at 5:45
1. File permissions in unix are written as UGA. That is, there are the
permissions
for the user that owns the file (U), permissions for the group that owns the
file (G)
and permissions for anyone else (A). As a numeric representation, each
permission is
written as a combination of 4+2+1 Where 4 = read, 2 = write, 1 = execute. If a
permission is 0, there are no permissions allowed.
So I am talking about a permission set of xx0 for UGA.
2. Active user on the file system is the user that is "mapped" onto the remote
filesystem. For instance, the local user ID for you might be asignh, but this
may not
exist on the remote file system, which means you are accessing files according
to the
policy for "anyone". In MacFUSE the "active user on the file system" is the
same as
the local user.
3. A file system where only root has access. I.e.
chown root:root myfile
chmod 770
No other user would have permissions on this. But I expect to be able to access
it
over SSHFS if I use root credentials to mount it.
4. Further to (2) above. In FUSE, the SSH user that is used to mount SSHFS is
considered the "active user on the file system". Any accesses to the file
system are
seen by the remote system as coming from the user that is used to access it. The
local user credentials are ignored.
I understand it is a different implementation in MacOS. But the underlying
principles
of file permissions / user credentials are the same because it is unix based.
So I
expected MacFUSE to map the file system access credentials to the user I use to
mount
the remote SSHFS share.
Original comment by james.si...@gmail.com
on 12 Jul 2007 at 6:04
> File permissions in unix are written as UGA.
Your statement as written sounded strange to me because Unix parlance for
"anyone" is "other". So it isn't
really UGA but UGO. In fact, if you man chmod(1) on OS X, you will see that 'a'
actually represents *all*
(equivalent to ugo), not other.
> In MacFUSE the "active user on the file system" is the same as the local user.
Yes, that is indeed as implemented in MacFUSE.
> the same because it is unix based.
That's a vastly oversimplified statement. We could discuss forever what "Unix
based" means, but there are
tons of differences despite all the Unix-basedness. Just because the concept of
file permissions exists in OS X
doesn't mean "everything" permissions related is handled the same way within
the Linux and OS X kernels/file
systems.
The MacFUSE version of sshfs tries to do the following (it should work in most
cases, but sometimes not,
depending on the ssh client/server in question, or how they have been
configured):
Let us say you are user ID u_local on the Mac OS X machine, and u_remote on the
SSH server machine.
u_remote can be 0, of course, as is in your case. When you mount a volume
through sshfs, it tries to "detect"
what u_remote is. Like I said, it should normally work.
If it did work, all incoming u_remote will be translated by sshfs to u_local.
So, on the Mac OS X machine, a
u_remote owned file on this sshfs volume will look like it's owned by u_local.
You can obviously tell if it
worked or not by doing an ls within the volume and seeing who's the owner of
such files.
Now, if you do a chown within such a volume, the currently released binary of
sshfs does *NOT* translate
u_local back to u_remote. The current source code checked into svn does, and
this behavior should be in the
next binary release of sshfs.
Note that even with the newest sshfs, a "chown root:root" will not work as you
are expecting--the idea is that
the "local" MacFUSE file system (not talking about sshfs, but the kernel part
of MacFUSE) should not be aware
of things like "remote" user IDs. The IDs are whatever reported by the
user-space file system--in this case,
sshfs. So, sshfs, and in general, any MacFUSE user-space file system, is the
one responsible for doing any
mapping/translation.
If this sounds "quirky" or undesirable to you, you can get the behavior you are
looking for by using the "-
odefer_auth" mount-time option. This option will disable any in-kernel
permission checks on the MacFUSE
side, so permission handling will be "whatever the ssh connection allows".
Original comment by si...@gmail.com
on 12 Jul 2007 at 6:38
It might be beneficial to place what you have just written in the Wiki under the
SSHFS section. As I said at the beginning, I don't believe this is a bug, but it
would be nice to know it is an intentional feature and not just overlooked.
Original comment by james.si...@gmail.com
on 12 Jul 2007 at 7:30
I'll extend the sshfs wiki page when I get a chance.
What I have written here has been discussed before though--in the macfuse-devel
mailing list, here in the
issues section, and to some extent, in the wiki (see the CHANGELOG pages for
MacFUSE Core and sshfs).
Marking this issue as invalid.
Original comment by si...@gmail.com
on 12 Jul 2007 at 7:43
Original issue reported on code.google.com by
james.si...@gmail.com
on 12 Jul 2007 at 3:10