Finder permissioning problem

[PeterStegemann]

Finder is using a root owned helper task "Locum" to perform some operations. With MacOS 10.7., this task is involved in Finders drag and drop operation. These operations fail on MacFUSE/osxfuse drives if they are not mounted with the "allow_other" option. Even though this could be considered as a Finder bug, I suggest changing the permission check in osdxfuse to address this issue and to give the users a flawless working version of osxfuse.

Form a technical perspective, the difference between 10.6. and 10.7. is visible in fuse_match_cred():

This is what we get on 10.7:

uid=502, ruid=0, groups[0]=20, gid=0, svgid=0

And this is what is expected (and is given by 10.6.):

uid=502, ruid=502, groups[0]=20, gid=20, svgid=20

One possible fix is to only check uid and groups in fuse_match_cred(), which seems to be sufficent. Or, as an alternative, only skip checking gid and svgid if they are 0.

[bfleischer]

I can't reproduce the various uid/gid values you are seeing.

On Snow Leopard I get three calls to fuse_match_cred with UID=0 RUID=0 GID=0 RGID=0 SVGID=0 (and a lot with the correct credentials) when I drag one file to the FUSE volume. From then on there are only calls to fuse_match_cred with the correct credentials UID=501 RUID=501 GID=20 RGID=20 SVGID=20.

On Lion I keep getting those UID=0 RUID=0 GID=0 RGID=0 SVGID=0 calls to fuse_match_cred on a regular basis.

As I understand it Snow Leopard falls back to the regular Finder process for moving/copying files after Locum is denied access to the FUSE volume (three times). Lion on the other hand does not seem to fall back on Finder but displays an error message instead.

[bfleischer]

Scratch my previous post. Now I'm seeing those calls to fuse_match_cred with UID=501 RUID=0 GID=20 RGID=0 SVGID=0

[PeterStegemann]

On Aug 18, 2011, at 14:45 , bfleischer wrote:

Scratch my previous post. Now I'm seeing those calls to fuse_match with UID=501 RUID=0 GID=20 RGID=0 SVGID=0

I was just thinking about how to reproduce this, as I didn't touch Lion for some weeks :-)

Regards,
Peter

[bfleischer]

I'm in favor of just checking EUID and EGID.

• Any process with EUID/EGID set to our UID/GID is able to change its RUID/RGID to those values. As I understand it checking RUID/GUID does help at all against an "attacker" (process with a different RUID/GUID) who is able to act on behalf of the user who mounted the file system.
• Any root process can change its UID/GID values to those of any user. Preventing a system process (EUID/EGUID=0) from accessing a FUSE file system is just a form of defense against a misbehaving file system that could hang the system process.

In short: Dropping the checks for RUID/RGID and SVGID should not create a new security thread.

[PeterStegemann]

I 100% agree. And it's a very local change with a low impact of breaking something that worked before.

[bfleischer]

Closed. Thanks Peter for tracking the issue down!