udevadm seems to set incorrect permissions for /dev/fuse

Bug #1152718 reported by Reuben Thomas
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Fix Released
Medium
Brian Murray

Bug Description

Last night I installed the update qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3

Afterwards, I discovered that I could no longer use FUSE, and from comparing time stamps, discovered that the permissions on my /dev/fuse had been changed to:

crw------T 1 root root 10, 229 Mar 8 07:48 /dev/fuse

at precisely the time that this update was running its postinst script. (/dev/fuse should have group fuse, not root, and group rw access.) The culprit appears to be udevadm:

udevadm trigger --subsystem-match=misc --action=change

This may be related to bug #1103022.

The full list of devices which had their permissions changed then is:

crw------- 1 root root 10, 58 Mar 8 07:48 alarm
crw------- 1 root root 10, 59 Mar 8 07:48 ashmem
crw------- 1 root root 10, 60 Mar 8 07:48 binder
crw------T 1 root root 10, 234 Mar 8 07:48 btrfs-control
crw------- 1 root root 10, 57 Mar 8 07:48 cpu_dma_latency
crw------- 1 root root 10, 61 Mar 8 07:48 ecryptfs
crw------T 1 root root 10, 229 Mar 8 07:48 fuse
crw------- 1 root root 10, 228 Mar 8 07:48 hpet
crw-rw----+ 1 root kvm 10, 232 Mar 8 07:48 kvm
crw------- 1 root root 10, 237 Mar 8 07:48 loop-control
crw------- 1 root root 10, 227 Mar 8 07:48 mcelog
crw------- 1 root root 10, 54 Mar 8 07:48 mei
crw------- 1 root root 10, 56 Mar 8 07:48 network_latency
crw------- 1 root root 10, 55 Mar 8 07:48 network_throughput
crw------- 1 root root 10, 1 Mar 8 07:48 psaux
crw-rw-r--+ 1 root root 10, 62 Mar 8 07:48 rfkill
crw------- 1 root root 10, 231 Mar 8 07:48 snapshot
crw-r----- 1 root root 10, 223 Mar 8 07:48 uinput
crw------- 1 root root 10, 53 Mar 8 07:48 vboxdrv
crw------- 1 root root 10, 52 Mar 8 07:48 vboxnetctl
crw------- 1 root root 10, 63 Mar 8 07:48 vga_arbiter

I can't see any other device that has incorrect permissions now, but I can't tell for all of the above what the correct permissions are.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: udev 175-0ubuntu13
ProcVersionSignature: Ubuntu 3.5.0-25.39-generic 3.5.7.4
Uname: Linux 3.5.0-25-generic x86_64
ApportVersion: 2.6.1-0ubuntu10
Architecture: amd64
CustomUdevRuleFiles: 10-vboxdrv.rules 99-lexscan.rules
Date: Fri Mar 8 18:43:14 2013
InstallationDate: Installed on 2011-05-24 (653 days ago)
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
MachineType: TranquilPC IXL
MarkForUpload: True
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-25-generic root=UUID=b14299ce-70d0-4b10-ab62-aff152625f36 ro quiet splash vt.handoff=7
SourcePackage: udev
UpgradeStatus: Upgraded to quantal on 2012-10-19 (139 days ago)
dmi.bios.date: 01/14/2011
dmi.bios.vendor: Intel Corp.
dmi.bios.version: BLH6710H.86A.0098.2011.0114.1739
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: DH67CF
dmi.board.vendor: Intel Corporation
dmi.board.version: AAG10215-203
dmi.chassis.type: 3
dmi.chassis.vendor: TranquilPC
dmi.modalias: dmi:bvnIntelCorp.:bvrBLH6710H.86A.0098.2011.0114.1739:bd01/14/2011:svnTranquilPC:pnIXL:pvr:rvnIntelCorporation:rnDH67CF:rvrAAG10215-203:cvnTranquilPC:ct3:cvr:
dmi.product.name: IXL
dmi.sys.vendor: TranquilPC

Revision history for this message
Reuben Thomas (rrt) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in udev (Ubuntu):
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote :

I was able to recreate this on raring but only when running the udev command under sudo e.g.

sudo udevadm trigger --subsystem-match=misc --action=change

Revision history for this message
Steve Langasek (vorlon) wrote :

I reproduced this here, and took a before/after snapshot of the /dev permissions. Most of the devices listed have been /touched/ by the command, which is expected, but their permissions have not been changed - the new permissions are still the correct ones.

The only exceptions are:

-crw-rw-rwT 1 root root 10, 229 Apr 11 08:48 fuse
+crw------T 1 root root 10, 229 Apr 17 11:21 fuse
-crw-rw-r--+ 1 root root 10, 62 Apr 11 08:48 rfkill
+crw-r--r--+ 1 root root 10, 62 Apr 17 11:21 rfkill

It's possible this is a fuse-specific problem rather than a udev problem. Looking further.

Revision history for this message
Steve Langasek (vorlon) wrote :

Ah. In /lib/udev/rules.d/50-udev-default.rules:

  KERNEL=="fuse", ACTION=="add", MODE="0666", OPTIONS+="static_node=fuse"

So most udev rules apply MODE settings unconditionally, but the fuse rule for some reason applies permissions only for ACTION==add. That means that when we rescan with --action=change, this device gets the default device permissions applied instead of the ones intended for /dev/fuse.

I think the correct fix here is to drop the 'ACTION=="add"', but this should be checked with upstream to be sure.

As for rfkill, I don't see what's causing the permission change. It may be an adverse interaction with udev-acl, I'm not sure.

Revision history for this message
Steve Langasek (vorlon) wrote :

Confirmed that this has been fixed upstream in later udev. So we should just drop this 'ACTION="add"' here.

Changed in udev (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Changed in udev (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Brian Murray (brian-murray)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udev - 175-0ubuntu26

---------------
udev (175-0ubuntu26) raring; urgency=low

  * Drop the add ACTION condition for the fuse rule (LP: #1152718)
 -- Brian Murray <email address hidden> Wed, 17 Apr 2013 14:22:30 -0700

Changed in udev (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.