ID Mapping In SSHFS (alert)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Change permissions of a remote share for "anyone" to 0
2. Mount that share via SSHFS with MacFUSE

What is the expected output? What do you see instead?

It is expected that the "active" user on the file system is the one we
connect as (like FUSE does). Instead, it is the credentials of the user
logged in to the local machine that are used. i.e. if I connect to a
root-only file system as root, I cannot read / write unless I use Terminal
/ login to the local system as root.

What version of the product are you using? On what operating system?

Mac OS 10.4.10
MacFUSE 0.40

Please provide any additional information below.

This may not be a bug so much as a quirk. I couldn't find anything about it
in the Wiki, so I worked around it by adding the appropriate GID
information that the local system sees in the mounted SSHFS fileshare to
the local Netinfo database, and adding the local user as a member of that
group.

Original issue reported on code.google.com by james.si...@gmail.com on 12 Jul 2007 at 3:10

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

> 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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Invalid