USB permissions not set at install time (udevd name changed?)

Bug #1540008 reported by Charles Lepple on 2016-01-30
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nut (Debian)
Fix Released
Unknown
nut (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Xenial
Undecided
Unassigned
Yakkety
Undecided
Unassigned
Zesty
Undecided
Unassigned

Bug Description

[Impact]

 * Installing nut provides rules to set up the devnodes accordingly, but
   on an install the trigger to run those is missed to be executed due to
   an error in postinst.

 * Fix is a backport from Debian repo
   (https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/id=d31c6dcb) , which works in artful already

[Test Case]

 * Plug in a usb controlled UPS of your choice
 * Install nut-server
 * The device node created should be mode 664 and group "nut", but it is
   not.
 * Install the proposed package with the fix
 * that should trigger the rules to run and it should now be created with
   proper permissions.

 * In the lack of special HW there is a fallback
 * Create a VM and give it some USB device
 * Start in one console "sudo udevadm monitor"
 * On installing the nut-server package the USB events should be re-triggered, but they are not yet today - with the fixed package they are.

[Regression Potential]

 * The postinst trigger never worked, now it will work. If on a system the
   rules fail to execute there might be an issue, but since the are only
   triggered (async udev) the install will not fail due to that. I think
   in the worst case they are just still not executed.
 * Vice versa once they are executed correctly the changed permission
   could be an issue for odd setups that relied on the broken permission,
   but I explained in the Regression potential section of bug 1099947 that
   is released together why I think that is no issue.

[Other Info]

 * n/a

----
1) $ lsb_release -rd
Description: Ubuntu 14.04.3 LTS
Release: 14.04

2) nut-server: 2.7.1-1ubuntu1; udev: 204-5ubuntu20.15

3) On a fresh install of Ubuntu 14.04 (amd64), I installed the nut-server package while the UPS was already connected via USB. After installation, the permissions described by /lib/udev/rules.d/52-nut-usbups.rules should have changed the group of the corresponding /dev/bus/usb/*/* node to 'nut'.

4) The owner/group for the /dev/bus/usb node remained root:root. Manually running 'udevadm trigger --subsystem-match=usb --action=change' changed the group to 'nut'. (From past experience tracking down related udev+nut bugs, unplugging and re-plugging the USB cable would yield similar results.)

However, that udevadm command is included in the postinst for nut-server, and it is guarded with a pidof check for 'udevd':

# ask udev to check for new udev rules
[ -x /etc/init.d/udev ] && pidof udevd > /dev/null \
      && udevadm trigger --subsystem-match=usb --action=change

This most likely needs to be amended to include the current process name, 'systemd-udevd'. I checked the control files, and unless the udevd process name has changed back, I believe this will affect vivid, wily and xenial as well as trusty. (I will let someone else add those later tags if that turns out to be the case.)

Charles Lepple (clepple) wrote :

Confirmed that this affects xenial as well.

tags: added: xenial
Changed in nut (Ubuntu):
status: New → Confirmed
Charles Lepple (clepple) wrote :

Patch for xenial: https://launchpadlibrarian.net/300873279/nut_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_2.7.4-0ubuntu7~xenial~libusb1~gb0e1758.diff.gz

I haven't tested the patch for trusty, but I assume it would be similar since the udevd binary has the same name.

Uploaded to PPA: https://launchpad.net/~clepple/+archive/ubuntu/nut/+packages

tags: added: patch
Changed in nut (Ubuntu Trusty):
status: New → Confirmed
Changed in nut (Ubuntu Xenial):
status: New → Confirmed
tags: added: server-next

Hi,
I beg your pardon that nobody found the time to look at this since I initially triaged it.
Especially since here even a suggested fix was provided we want to encourage and help.
I'm currently trying to clear out bugs that are dormant for too long, so lets take a look.

Status on the checked program:
Trusty to Artful : /lib/systemd/systemd-udevd is the binary
Due to changes in the nit system they are started differently, but that actually doesn't matter.
On Debian the name matches what Ubuntu has - so the issue as well as the fix applies to Debian as well.

IMHO - it isn't so important that the files are there.
The requiremend is
1. udevadm available
2. udev running
So a much better check could anyway be something like:
  systemctl is-active udev && which udevadm > /dev/null

For all but trusty that should be much better and we will find a pendant there once SRU'ing.
I'll prepare something for Debian and we can think on Fix and SRU once that has settled.
I'll link the Debian bug here soon ...

Changed in nut (Ubuntu Yakkety):
status: New → Triaged
Changed in nut (Ubuntu Zesty):
status: New → Triaged
Changed in nut (Ubuntu Artful):
status: Confirmed → Triaged
Changed in nut (Ubuntu Xenial):
status: Confirmed → Triaged
no longer affects: nut (Ubuntu Artful)

Hmm when prepping the changes to Debian I found it waiting in the suggested form for release already in reference to the Ubuntu bug.

[1]: https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/?id=d31c6dcb

So since it is accepted already no need to push my new way of thinking how to better check for the service. The benefit is that this way it also applies to Trusty as-is.

Also we carry Delta anyway - so it wouldn't be fixed by a sync.
Next steps:
1. Pull [1] into Artful
2. Prep SRUs back to X/Y/Z/T

[1]: https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/?id=d31c6dcb

As a sync would be preferred for 1. of comment #5 I did:
- Poll Debian on the status of the release of the already queued changes [1].
- Link the Debian bug up here and waiting for a reply now.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868007

Changed in nut (Debian):
status: Unknown → New
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.7.4-5ubuntu4

---------------
nut (2.7.4-5ubuntu4) artful; urgency=medium

  * d/p/fix-snmp-driver-compile-options.patch: fix cflags/ldflags
    mismatch (LP: #1711092).
  * d/libnutclient0.symbols: fix symbols in regard to gcc-7 (LP: #1711091).

 -- Christian Ehrhardt <email address hidden> Wed, 16 Aug 2017 12:44:26 +0200

Changed in nut (Ubuntu):
status: Triaged → Fix Released
Changed in nut (Ubuntu Yakkety):
status: Triaged → Won't Fix
description: updated

Uploaded SRU changes for review - branches are linked

Hello Charles, or anyone else affected,

Accepted nut into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.2-4ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nut (Ubuntu Xenial):
status: Triaged → Fix Committed
tags: added: verification-needed verification-needed-xenial
Changed in nut (Ubuntu Trusty):
status: Confirmed → Fix Committed
tags: added: verification-needed-trusty
Chris J Arges (arges) wrote :

Hello Charles, or anyone else affected,

Accepted nut into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.1-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nut (Ubuntu Zesty):
status: Triaged → Fix Committed
tags: added: verification-needed-zesty
Chris J Arges (arges) wrote :

Hello Charles, or anyone else affected,

Accepted nut into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.4-5ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Charles Lepple (clepple) wrote :

Chris and Christian, thanks for working on this!

For xenial, looks like this debian/ patch might have gotten dropped (other half of the 52--nut-usbups.rules renaming), which might be causing the build failure: https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/?id=b0b61548a47b153b1ce6205bb9ce47edbb32910f

Hmm, I'm sure this built in a ppa for me - I'll look back into that in a few days (after Feature Freeze buzz) and report back.

Hi Charles,
thanks for your immediate feedback. In retrospective I had the change applied differently when testing and cherry picked it the same way as in later relases on the actual MP for upload.
It is very charming and heart warming that you come back so fast on a bug dormant by us for so long.

The other SRU that was combined with this on Xenial seems fixed on Xenial via other updates.
So I removed that part completely to refresh this upload - it is now building fine.

I'll upload that as new MP and hope to get an ack and sponsoring into unapproved today.
From there the SRU Team will pick it up and we will get an update here to re-consider.

I beg (all) your pardon for that hiccup on the way to finally fix this.

Re-verified that it builds now fine on all arches for Xenial.

I took a Xenial VM Guest and also pre-verified that

0. on a correct (manual) trigger I'd see in udevadm monitor the root hub and the device to show up as event
=> ok, working

1. on install of the old nut-server package there is no trigger
=> issue confirmed, no trigger

2. on install of the new SRU there is the trigger that would fix up permissions on install as intended
=> now working correctly re-emitting the events (and only usb events)

I'm moving that into the test steps, as it allows one wirthout special HW to *somewhat* test he SRU.

description: updated

The other issue we wanted to fix in the same SRU is also fixed in Trusty by another (yet unknown fix, maybe to udev). The rules there are no more later overwritten - so I have to refresh the SRU upload to trusty as I only want/can SRU a verifiable fix.

I beg (all) your pardon for this hickup, but the lack of special HW made me unable to pre-verify that. Fortunately this issue over there while effectively hitting peopl with special HW - it can be verified without (as described in the test steps).

This would conflict with the SRU policy so I prepared an updated version to upload "over" it into proposed and let that then be verified and migrate.
That said - preparing a new upload for Trusty (Xenial and Zesty uploads are good already).

New MP to consider is at:
https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+merge/329714

While we still wait for acceptance of 2.7.2-4ubuntu1.2 in Xenial and review,sponsoring and acceptance of 2.7.1-1ubuntu1.2 for Trusty we can test the Zesty upload already.

$ sudo udevadm monitor
[in another console install the fixed nut-server package]
KERNEL[134.190774] change /devices/pci0000:00/0000:00:01.2/usb1 (usb)
UDEV [134.192149] change /devices/pci0000:00/0000:00:01.2/usb1 (usb)
KERNEL[134.192328] change /devices/pci0000:00/0000:00:01.2/usb1/1-0:1.0 (usb)
UDEV [134.193343] change /devices/pci0000:00/0000:00:01.2/usb1/1-0:1.0 (usb)

Working correctly now -> verified (for zesty)

tags: added: verification-done-zesty
removed: verification-needed-zesty

Fixed Trusty reviewed and uploaded for SRU consideration as well now.
I'll reset the state of the Trusty&Xenial Tasks so it shows up in the SRU Teams process again to accept those over the ones currently in proposed.

Changed in nut (Ubuntu Xenial):
status: Fix Committed → In Progress
Changed in nut (Ubuntu Trusty):
status: Fix Committed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.7.4-5ubuntu2.1

---------------
nut (2.7.4-5ubuntu2.1) zesty; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)

 -- Christian Ehrhardt <email address hidden> Thu, 17 Aug 2017 15:26:30 +0200

Changed in nut (Ubuntu Zesty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for nut has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Brian Murray (brian-murray) wrote :

I've accepted the Trusty and Xenial SRUs but something with our tooling broke and this bug was not commented on.

Charles Lepple (clepple) wrote :

I uninstalled NUT on xenial, rebooted, confirmed that ownership was root:root, enabled xenial-proposed, and installed nut-server 2.7.2-4ubuntu1.2. The ownership was successfully changed to root:nut.

tags: added: verification-done-xenial
removed: verification-needed-xenial

Thanks Brian for accepting, I worked on hacking the changes files to be correct for this special case with rbasak - but given your comment it seems it didn't work out :-/

Thanks Charles for confirming Xenial.
Zesty already migrated (lacking the extra hop to unroll the no more needed part for another bug).

That leaves Trusty to be verified - I did so today, to get this migrating somewhat together.
Attaching a full log of that test ...

tags: added: verification-done verification-done-trusty
removed: verification-needed verification-needed-trusty

Per former comment setting Trusty and the general verification tag to done.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.7.1-1ubuntu1.2

---------------
nut (2.7.1-1ubuntu1.2) trusty; urgency=medium

  * Drop d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: this issue
    seems fixed via other updates and is no more reproducible (LP 1099947).

nut (2.7.1-1ubuntu1.1) trusty; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)
  * d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: make udev
    rule apply correctly (LP 1099947).

 -- Christian Ehrhardt <email address hidden> Mon, 28 Aug 2017 08:48:47 +0200

Changed in nut (Ubuntu Trusty):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.7.2-4ubuntu1.2

---------------
nut (2.7.2-4ubuntu1.2) xenial; urgency=medium

  * Drop d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: this issue
    seems fixed via other updates and is no more reproducible (LP 1099947).
    Also fixes a FTBFS on the ongoing SRU of 2.7.2-4ubuntu1.1.

nut (2.7.2-4ubuntu1.1) xenial; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)
  * d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: make udev
    rule apply correctly (LP 1099947).

 -- Christian Ehrhardt <email address hidden> Thu, 24 Aug 2017 09:47:35 +0200

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

Other bug subscribers

Remote bug watches

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