Bug 10840

Summary:	sshfs fails to mount remote fs since recent updates
Product:	Mageia	Reporter:	Barry Jackson <zen25000>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	Normal	CC:	mageia
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

Description Barry Jackson 2013-07-26 01:07:05 CEST

Description of problem:
[baz@jackodesktop ~]$ sshfs baz@zmhost:/zm-repo/pub/linux/barjac/distrib/ $HOME/iurt_uploads/iurt/
fuse: failed to open /dev/fuse: Permission denied

The same mount works correctly from Mga3 and has always worked until a couple of days ago from Cauldron.

I can still connect to the server over ssh from Cauldron.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


Reproducible: 

Steps to Reproduce:

Comment 1 Barry Jackson 2013-07-26 12:31:25 CEST

[root@jackodesktop baz]# usermod -G fuse baz
usermod: group 'fuse' does not exist

This would explain the 'permission denied' - but why has fuse group gone AWOL?

Comment 2 Colin Guthrie 2013-07-26 13:19:59 CEST

Did it ever exist?

It's perhaps related to a systemd change where static device nodes are no longer created by udev but deferred to kmod.

This might affect the ACLs on /dev/fuse. Can you check if you had ACL privs on /dev/fuse under mga3 and that there are no ACLs on mga4? If so probably helps narrorw down the problem (and is likely related to kmod+systemd)

CC: (none) => mageia

Comment 3 Barry Jackson 2013-07-26 13:49:27 CEST

This is not related to systemd in initrd as I am now back with original initrd.

Mga4:
[baz@jackodesktop ~]$ getfacl /dev/fuse
getfacl: Removing leading '/' from absolute path names
# file: dev/fuse
# owner: root
# group: root
user::rw-
group::---
other::---

Mga3
getfacl: Removing leading '/' from absolute path names
# file: dev/fuse
# owner: root
# group: root
user::rw-
group::rw-
other::rw-

Comment 4 Barry Jackson 2013-07-26 14:23:42 CEST

Changing perms in Mga4 to match Mga3 does fix sshfs mount issue.

Comment 5 Colin Guthrie 2013-07-26 14:56:41 CEST

OK, so checking the udev rules, it seems that the perms are meant to be open:

[colin@jimmy ~]$ cd /usr/lib/udev/rules.d/
[colin@jimmy rules.d]$ grep fuse *
50-udev-default.rules:KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"
99-systemd.rules:SUBSYSTEM=="module", KERNEL=="fuse", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"


i.e. 666

I suspect this is a problem reported on the systemd mailing list a couple days ago regarding tmpfiles overwriting the perms of the kmod static nodes.

http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/12121

This isn't the final patch, but the principle is sound and seems like what's happening here.

Will look to apply one of the patches.

Comment 6 Colin Guthrie 2013-07-26 15:05:28 CEST

OK, the upstream commits are cherry picked but will keep open until I've had the chance to reboot and confirm the fix :)

Comment 7 Colin Guthrie 2013-07-27 13:32:52 CEST

Those patches work for me. /dev/fuse has the expected permissions. Submitted to BS now.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 8 Barry Jackson 2013-07-27 14:44:45 CEST

Nice!
Confirmed here after update and reboot perms are correct.