udevadm trigger --action=change not working in quantal and raring

Bug #1092715 reported by Serge Hallyn on 2012-12-20
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
qemu-kvm (Ubuntu)
Low
Unassigned
Raring
Low
Serge Hallyn

Bug Description

For bug 1057024, we have qemu-kvm postinst call udevadm trigger --action=change. This is to make udev recalculate permissions for /dev/kvm based on the new /lib/udev/rules.d/40-qemu-kvm.rules file.

In precise, this causes /dev/kvm's acls to be correctly set so that group has rw permissions.

In quantal, with the exact same rules file, it does not. After a reboot, permissions are set correctly. But manually running udevadm trigger --subsystem=misc --action=change (or variations of that) does not change the group acl. It changes the group ownership, and part of the acl, but not the group acl.

Related branches

Serge Hallyn (serge-hallyn) wrote :

Marking confirmed based upon sighting by adam_g

Changed in udev (Ubuntu):
importance: Undecided → Critical
status: New → Confirmed
Serge Hallyn (serge-hallyn) wrote :

This only happens when a user is logged in.

Serge Hallyn (serge-hallyn) wrote :

Normally when I 'chmod g+rw /dev/kvm' (or 'chmod g+rw /tmp/xxx' for manual tests), the group acl gets set correctly. (even in raring)

But in quantal it stays '---'.

So I actually don't think udev is to blame. I don't know if consolekit could be quickly resetting, or if this could be a filesystem/kernel bug.

Serge Hallyn (serge-hallyn) wrote :

I'm now convinced this is a kernel bug.

If I do
   touch xxx
   setfacl -m g::--- xxx
   strace -f -ooutput chmod g+rw xxx
   getfacl xxx

I see that the group acl for xxx is changed to include rw, and the file 'output' shows that chmod simply calls the fchmodat syscall, which uses notify_change to update the acl.

If I do
   # make sure to be logged into console
   sudo apt-get purge qemu-kvm
   sudo modprobe kvm_intel
   sudo apt-get install qemu-kvm
   getfacl xxx
   # see that group acl is still ---
   sudo chmod g+rw /dev/kvm
   # see that group acl is still ---

So the kernel is meant to be updating the acl in fchmodat, but is not doing it. I will try a xfs-backed VM to see if the bug is in ext4 itself, or in the generic fs code.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1092715

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: quantal
no longer affects: udev (Ubuntu)
tags: added: bot-stop-nagging
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → High
description: updated
summary: - udevadm trigger --action=change not working since quantal?
+ chown does not update acls if there are >1 user acls (in quantal)

Sorry, it seems my test was bad in raring. chown does not clear the acls anywhere, so udev needs to do it. re-marking for udev.

summary: - chown does not update acls if there are >1 user acls (in quantal)
+ udevadm trigger --action=change not working in quantal
Changed in udev (Ubuntu):
status: New → Confirmed
importance: Undecided → High
description: updated
summary: - udevadm trigger --action=change not working in quantal
+ udevadm trigger --action=change not working in quantal and raring
Serge Hallyn (serge-hallyn) wrote :

The cause of the problem is simply the udev-acl call in 70-udev-acl.rules. Since this is a higher # rule than 40-qemu-kvm.rules, it gets run after.

The problem can be solved by:

1. moving 40-qemu-kvm.rules to 72-qemu-kvm.rules
2. making qemu-kvm depend on acl
3. appending RUN+="/usr/bin/setfacl -m g::rw /dev/kvm" to 72-qemu-kvm.rules.

no longer affects: linux (Ubuntu)
affects: udev (Ubuntu) → qemu-kvm (Ubuntu)
Changed in qemu-kvm (Ubuntu Quantal):
status: New → Confirmed
Changed in qemu-kvm (Ubuntu Precise):
status: New → Confirmed
Changed in qemu-kvm (Ubuntu Quantal):
importance: Undecided → High
Changed in qemu-kvm (Ubuntu Precise):
importance: Undecided → High
Serge Hallyn (serge-hallyn) wrote :

Actually qemu-kvm.rules can stay at 40 by using :=, so the rules file becomes

KERNEL=="kvm", GROUP:="kvm", MODE:="0660", TAG:="", RUN:="/usr/bin/setfacl -m g::rw /dev/kvm"

Serge Hallyn (serge-hallyn) wrote :

(replacing /dev/kvm with $env{DEVNAME} of course)

Serge Hallyn (serge-hallyn) wrote :

I prefer to fix this bit through bug 1103022. May mark this one invalid. It has been further obfuscated by the presence of an apparent inotify bug stopping udev from seeing updates on some systems.

Changed in qemu-kvm (Ubuntu Raring):
status: Confirmed → In Progress
assignee: nobody → Serge Hallyn (serge-hallyn)
Serge Hallyn (serge-hallyn) wrote :

this bug will likely neer be fixed as it is due to wrongly copied group acl by udev-acl. udev-acl is going away soon, which will remove this bug. For nwo it is being worked around in qemu by postinst changing the group acl before callnig udevadm trigger. As soon as we switch from consolekit to logind, udev-acl, and hence this bug, will go away.

Serge Hallyn (serge-hallyn) wrote :

won't be fixing this here, and marking low priority as its being worked around successfully.

Changed in qemu-kvm (Ubuntu Raring):
importance: High → Low
status: In Progress → Won't Fix
Changed in qemu-kvm (Ubuntu):
assignee: Serge Hallyn (serge-hallyn) → nobody
status: In Progress → Won't Fix
no longer affects: qemu-kvm (Ubuntu Precise)
no longer affects: qemu-kvm (Ubuntu Quantal)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers