SuperDuper! backup fails as it encounters MacFUSE-mounted volumes

[GoogleCodeExporter]

Probably not an issue with MacFUSE, but just in case:

<http://www.shirt-pocket.com/fogbugz/default.php?39320_XGRU>

Original issue reported on code.google.com by grahampe...@gmail.com on 27 Apr 2007 at 9:27

[GoogleCodeExporter]

I intended to cross-reference 
from <http://www.shirt-pocket.com/fogbugz/default.php?39320_XGRU>
to this <http://code.google.com/p/macfuse/issues/detail?id=156> but the former 
is read-only with no 
option to create an account for myself so I'll add notes here. 

process SDCopy and its parent 
process SDAgent both run as root for this type of standard backup

their parent 
process SuperDuper runs as the user who initiated the backup. 

Original comment by grahampe...@gmail.com on 27 Apr 2007 at 9:53

[GoogleCodeExporter]

I explained this already: if the MacFUSE volume was mounted by a user with UID 
N, then only processes with UID 
N can access that volume by default. Nobody else, not even the super user, can 
access that volume.

You can use the "allow_other" option to change this behavior. To use 
"allow_other", you must be the super user.

Original comment by si...@gmail.com on 27 Apr 2007 at 11:01

[GoogleCodeExporter]

Thanks for the reminder ... I do recall the concept, but couldn't immediately 
find the earlier explanation 
<http://code.google.com/p/macfuse/issues/detail?id=151#c2>. 

sshfs -h 
includes 
allow_root
but not 
allow_other

I expect that the developers of SuperDuper! will want to enhance their 
application. 

Thanks again
Graham

Original comment by grahampe...@gmail.com on 27 Apr 2007 at 2:06

[GoogleCodeExporter]

grahamperrin:

Try "-oallow_other" still (even though it might not be listed in the output of 
"sshfs -h"). I think the help entry for 
allow_other got left out.

Original comment by si...@gmail.com on 27 Apr 2007 at 3:33

[GoogleCodeExporter]

Does -oallow_other allow access by _all_ other users? 

If so, I shouldn't opt for this. (Security is preferred.)

Thanks

Original comment by grahampe...@gmail.com on 27 Apr 2007 at 3:58

[GoogleCodeExporter]

It allows access to all users in the sense that *blanket* access denial is not 
performed by MacFUSE for any user. 
File permissions etc. are still honored.

Maybe it'd be useful to have a 'allow_users=uid1,uid2,...,uidN' type of option 
that's settable only by the super 
user, but allows access to the given users and does blanket denial for 
everybody else.

Original comment by si...@gmail.com on 27 Apr 2007 at 4:02

[GoogleCodeExporter]

Looks like the program you're using is just running into the blanket permission 
denial MacFUSE performs by 
default.

Original comment by si...@gmail.com on 2 May 2007 at 5:27

• Changed state: Invalid

[GoogleCodeExporter]

Echoed in 

1) a request for a MacFusion GUI for option
allow_root
<http://code.google.com/p/macfusion/issues/detail?id=16>

and 

2) less specifically, a simple/interim MacFusion GUI for 
all command-line options
<http://code.google.com/p/macfusion/issues/detail?id=28>

allow_root option should be very useful in various situations.

###

Off-topic: SuperDuper! aside, two other applications spring immediately to mind:

Disk Inventory X <http://www.derlien.com/>
JDiskReport <http://www.jgoodies.com/freeware/jdiskreport/>

-- either one launched using Rooter (previously available from 
<http://macmagna.free.fr/>) which neatly runs an application as root for lesser 
users.

Original comment by grahampe...@gmail.com on 4 May 2007 at 4:51

[GoogleCodeExporter]

allow_root is not a good idea in general. Enabling it by default (without a 
user explicitly enabling it) would be 
lame because that defeats the purpose of the blanket permission denial MacFUSE 
does to help alleviate the 
potential security concerns. Just because something makes it apparently 
"convenient" doesn't mean it's a good 
idea.

That aside, allow_root is implicitly ineffective (not enabled in the code 
itself) in all versions of MacFUSE 
released so far. Currently MacFUSE won't let you set allow_root unless you are 
already root. But if you're 
already root, setting allow_root would be silly.

A non-root user *should* be able to specify allow_root, but that user must be a 
member of the "MacFUSE 
admin" group. What should be the admin group is a good question. MacFUSE will 
allow the superuser to 
configure (dynamically, through the sysctl command) the gid of the MacFUSE 
admin group. To make things 
more convenient, when the MacFUSE kext is loaded, the gid will be initially set 
to the Mac OS X admin gid. In 
short, if you don't reconfigure anything, then, out of the box, a Mac OS X 
admin user will automatically also be 
a MacFUSE admin user. This addition will be in the next release.

Original comment by si...@gmail.com on 12 May 2007 at 9:01

[GoogleCodeExporter]

Re comment 9 above:

I'll draw this to the attention of Michael Gorbach (MacFusion). 

At <http://code.google.com/p/macfusion/wiki/sshfsstatichelp> I have partially 
reproduced (and linked to) 
Amit's comment elsewhere regarding the architectural decision. 

<http://code.google.com/p/macfusion/issues/detail?id=16#c6> has been labelled 
as a security issue (but 
not a defect; in the MacFusion GUI context my wish is for the user to easily 
understand the implications of 
experimenting with options such as allow_root).

The greatest surprise to me is that blanket denial can apply to root. Not 
because it shouldn't — after reading 
about the architectural decision, I understand why it's applied here — but 
because … 

… I was about to mention "all the systems I have managed", then realised 
that everything UNIX-like that I have 
managed has been Mac (from the earliest OS X Server (!) and the earliest OS X, 
through to OS X Server 10.3.9 
and OS X 10.4.9). Plus, a very little Ubuntu and other Linux. 

Bottom lines: 

    * this was my first encounter of an environment in which access
    can be denied to the root user

    * I'm unfamiliar with UNIX beyond Mac, so I should expect some
    surprises (now, and in 10.5).

Thanks again to Amit!

Original comment by grahampe...@gmail.com on 12 May 2007 at 2:25

[GoogleCodeExporter]

The denial to root is not to protect users from root, but to protect root (the 
system really) from a malicious or 
inadvertently misbehaving user program messing up the system. What MacFUSE does 
(making a user program act 
like a file system) is not common--it makes the kernel depend on a user 
program. Therefore, one of the 
precautions it takes (disallowing root by default) is also an uncommon step. 
Even then, I'm surprised you find it 
surprising--ACLs can work like that too, and ACLs have been around for some 
time now.

Original comment by si...@gmail.com on 12 May 2007 at 8:48

[GoogleCodeExporter]

I figured as much. Thanks for confirming. 

ACLs: I understand the benefits, but I'm not as familiar as I should be. My 
three AMP licenses for Mac OS X Server 
are sitting, unused, on the shelf; as much as I'd like to upgrade to Mac OS X 
Server 10.4.9, I've been awaiting 
local infrastructure improvements (fibre channel connections to SAN, things 
like that) before diving in. 

I realise that ACLs are not limited to the Server flavour of Mac OS X, but you 
get the picture ... basically, the need 
for me to apply (or learn more about) ACLs has not arisen before now. 

Original comment by grahampe...@gmail.com on 12 May 2007 at 9:57

[GoogleCodeExporter]

Incidentally, it has been a long time since I had a problem with SuperDuper! 

AFAIK the resolution was because 

> User and group ID mapping is now turned on by default

<http://code.google.com/p/macfuse/wiki/MACFUSE_FS_SSHFS> 

If you like, set the status of this issue to 
Verified

Thanks
Graham

Original comment by grahampe...@gmail.com on 3 Jul 2007 at 10:21