Bug 903074

Summary: android-tools: please fix or remove (non useful) udev rule
Product: [Fedora] Fedora Reporter: Kay Sievers <kay>
Component: android-toolsAssignee: Ivan Afonichev <ivan.afonichev>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ivan.afonichev, travneff
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-09 23:36:32 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Kay Sievers 2013-01-23 00:10:19 EST
The rules file:
  /usr/lib/udev/rules.d/51-android.rules
contains matches like:
  SUBSYSTEM=="usb", ATTR{idVendor}=="8087", 

which are "Intel" and match on USB "Root Hubs" which are found on, I guess, 80%
of all machines out there. This makes no sense, really.

Also, udev cannot be used to start services, udev will track all processes
and kill them after 30 seconds of udev idle time. Services need to be started
by systemd. Udev only supports executing very short running processes, never
services.

The server should likely be converted to a systemd service, which is manually
enabled on systems that want to start it. Starting it on-demand based on USB
ids is almost impossible, unless you want to maintain a list of product too,
the vendor alone surely makes no sense, because almost every box contains an
Intel, or any of the other vendors, USB device.

As an alternative, the server could be patched to support socket activation,
inetd-style or systemd style, and when the clients tries to connect, the system
will start it on-demand.

Currently, the server is started on every box, I've check, where the
android-tools are installed.

Thanks!
Comment 1 Ivan Afonichev 2013-01-23 17:34:15 EST
Due to security issues(879585,894745) we need to run service as unprivileged user so we need something like:
SUBSYSTEM=="usb", ATTR{idVendor}=="8087", MODE="0664", GROUP="usb_rw", TAG+="systemd", ENV{SYSTEMD_WANTS}="adb.service"
Or if we chouse not to start service on plugging:
SUBSYSTEM=="usb", ATTR{idVendor}=="8087", MODE="0664", GROUP="usb_rw"

(
service is configured to start as
User=adb
Group=usb_rw
)

I'am also researching some workarounds with running service as root(it seems not so good idea to set group for all Intel usb devices).
I'll try "PrivateTmp=true" systemd parameter.
Comment 2 Kay Sievers 2013-01-23 18:10:20 EST
As mentioned, on-demand activation based on "IS there an Intel USB device"
makes no sense really.

You are better off turning that thing into a normal service which users can
enable, or which even gets unconditionally enabled at package install time.

On-demand activation is pointless if it happens at ~80% of all machines,
we should not do such stuff, it's the wrong model.

The only sensible on-demand activation is based on strict product, not
vendor-only matches, or based on starting the client tool, which triggers
starting the server (socket activation).

Please turn that thing into a simple service to enable/disable, or make it
socket activated, but leave the udev matching alone, it's really pointless to
match on a long list of huge computer vendors to start a very specialized service. That's really not what udev is for, and not how things should work.
Comment 3 Andrew Travneff 2013-01-25 12:00:03 EST
+1 for converting this into a service or at least marking 51-android.rules as config in rpm. Remove it would be ok for me, but I don't want to break the package.
Comment 4 Fedora Update System 2013-01-29 13:50:19 EST
android-tools-20130123git98d0789-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/android-tools-20130123git98d0789-1.fc16
Comment 5 Fedora Update System 2013-01-29 13:50:41 EST
android-tools-20130123git98d0789-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/android-tools-20130123git98d0789-1.fc17
Comment 6 Fedora Update System 2013-01-30 15:57:40 EST
android-tools-20130123git98d0789-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/android-tools-20130123git98d0789-1.fc18
Comment 7 Fedora Update System 2013-02-01 11:29:52 EST
Package android-tools-20130123git98d0789-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing android-tools-20130123git98d0789-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-1666/android-tools-20130123git98d0789-1.fc16
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2013-02-09 23:36:34 EST
android-tools-20130123git98d0789-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2013-02-09 23:37:01 EST
android-tools-20130123git98d0789-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2013-02-09 23:37:54 EST
android-tools-20130123git98d0789-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.