Bug 559412 - Can't connect to remote as regular user (again) - ACLs this time
Can't connect to remote as regular user (again) - ACLs this time
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: udev-maint
Fedora Extras Quality Assurance
: Reopened
: 622674 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-27 21:27 EST by Adam Williamson
Modified: 2012-01-24 14:57 EST (History)
9 users (show)

See Also:
Fixed In Version: libconcord-0.23-9.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-24 14:56:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2010-01-27 21:27:54 EST
So a while back I reported a bug that concordance can't connect to the remote as a regular user:

https://bugzilla.redhat.com/show_bug.cgi?id=506371

well, it's baaaack! Only this time, it's because of ACLs:

[adamw@adam SRPMS]$ concordance -i
Concordance 0.21
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

ERROR: Couldn't initializing libconcord: Error connecting or finding the remote
[adamw@adam SRPMS]$ su
Password: 
c[root@adam SRPMS]# concordance -i
Concordance 0.21
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

Requesting Identity: 100%                 done
  Model: Logitech Harmony 880 (Espresso)
  Firmware Version: 4.4
  Hardware Version: 1.8
  Config Flash Used: 24% (463 of 1920 KiB)
[root@adam SRPMS]# getfacl /dev/harmony-3-2 
getfacl: Removing leading '/' from absolute path names
# file: dev/harmony-3-2
# owner: root
# group: root
user::rw-
group::rw-
other::r--
[root@adam SRPMS]# setfacl -m u:adamw:rw /dev/harmony-3-2
[root@adam SRPMS]# getfacl /dev/harmony-3-2
getfacl: Removing leading '/' from absolute path names
# file: dev/harmony-3-2
# owner: root
# group: root
user::rw-
user:adamw:rw-
group::rw-
mask::rw-
other::r--
[root@adam SRPMS]# exit
exit
[adamw@adam SRPMS]$ concordance -i
Concordance 0.21
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.

Requesting Identity: 100%                 done
  Model: Logitech Harmony 880 (Espresso)
  Firmware Version: 4.4
  Hardware Version: 1.8
  Config Flash Used: 24% (463 of 1920 KiB)

Success!

So, yeah, we need the udev rules to set the correct ACLs on the device node, not just the old-school permissions.
Comment 1 Bug Zapper 2010-03-15 10:15:20 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Sopho M 2010-04-12 22:02:49 EDT
For now, following the readme in the source, I created a new file:

/etc/udev/rules.d/99-custom-concordance.rules 

and wrote the following line in it:

SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c110", MODE="666"

Note that the vendor and product need to match those of the remote. You can use lsusb to figure that out.
Comment 3 Adam Williamson 2011-01-24 02:09:47 EST
adding harald to CC as handling ACL stuff with udev seems a bit...hairy.

http://www.spinics.net/lists/hotplug/msg03913.html

harald, do we have to get you to patch this into udev?
Comment 4 Harald Hoyer 2011-01-25 10:04:20 EST
The new masterplan is, to categorize devices, and assign ACLs accordingly.

So in case of PDAs, the pda rpm provides rules to set ENV{ID_PDA}=1 for certain vendor/product ids. The udev package then manages ACLs for all ID_PDA tagged devices.

So, here we could flag 

SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c110", ENV{ID_???}=1

You just have to think of a meaningful category, and then we can persuade Kay, to manage ACLs for this category from within udev.
Comment 5 Adam Williamson 2011-01-25 10:48:47 EST
depends how generic you want the category to be; I mean, ultimately what this *is* is a user-programmable piece of hardware. We could say HARMONY_REMOTE but that'd be too specific. PROGRAMMABLE_REMOTE ? or go even more generic and have PROGRAMMABLE_DEVICE ?
Comment 6 Adam Williamson 2011-03-16 15:19:04 EDT
harald: ping?
Comment 7 Adam Williamson 2011-03-16 15:19:21 EDT
*** Bug 622674 has been marked as a duplicate of this bug. ***
Comment 8 Adam Williamson 2011-03-16 15:20:07 EDT
still valid up to f15, of course.
Comment 9 Harald Hoyer 2011-03-17 04:25:24 EDT
(In reply to comment #6)
> harald: ping?

Yes? Does the package have a ENV{ID_???}=1 udev rules now? If not, please add them. Then I can change the udev master rule for ACLs to grant ACLs on ENV{ID_???}==1.
Comment 10 Adam Williamson 2011-03-17 12:12:17 EDT
No, I was under the impression the category name should be approved by somebody. If not, I'll just go ahead and add one of those proposed above.
Comment 11 Adam Williamson 2011-03-17 12:31:09 EDT
So, before I commit this, just to make sure, it changes /etc/udev/rules.d/99-libconcord.rules so that all lines like:

ATTR{idVendor}=="046d", ATTR{idProduct}=="c110", SYMLINK+="harmony-%k"

now read:

ATTR{idVendor}=="046d", ATTR{idProduct}=="c110", SYMLINK+="harmony-%k", ENV{ID_PROGRAMMABLE_REMOTE}=1

is that correct?
Comment 12 Harald Hoyer 2011-03-17 13:07:09 EDT
ok, then I will have to add to /lib/udev/rules.d/70-acl.rules

ENV{ID_PROGRAMMABLE_REMOTE}=="1", TAG+="udev-acl"
Comment 13 Adam Williamson 2011-03-17 14:11:14 EDT
OK, I'm pushing builds with that change through right now. Rawhide is pushed, F15 is going, and I will also do F14.
Comment 14 Adam Williamson 2011-03-17 14:29:15 EDT
Harald, I've pushed the libconcord builds; can you do udev builds for f14 and f15, then we can submit the two packages together as an update? Thanks.
Comment 15 Harald Hoyer 2011-03-17 15:35:09 EDT
(In reply to comment #14)
> Harald, I've pushed the libconcord builds; can you do udev builds for f14 and
> f15, then we can submit the two packages together as an update? Thanks.

I am sorry, Kay wants ID_REMOTE_CONTROL and not ID_PROGRAMMABLE_REMOTE .. and you should not set the symlink, because it's not needed.
Comment 16 Adam Williamson 2011-03-17 15:44:32 EDT
OK, will adjust. I don't think taking out the symlink downstream is appropriate, that should probably happen upstream. We can report it upstream if you like, though.
Comment 17 Adam Williamson 2011-03-17 20:56:47 EDT
I've pushed libconcord builds with ID_REMOTE_CONTROL now.
Comment 18 Adam Williamson 2011-03-21 14:35:58 EDT
harald: ping? can you push an updated udev to koji, please? I'd really like to push the fixes together.
Comment 20 Fedora Update System 2011-03-23 12:55:00 EDT
udev-166-2.fc15,libconcord-0.23-5.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/udev-166-2.fc15,libconcord-0.23-5.fc15
Comment 21 Fedora Update System 2011-03-23 12:58:48 EDT
libconcord-0.23-5.fc14,udev-161-9.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libconcord-0.23-5.fc14,udev-161-9.fc14
Comment 22 Fedora Update System 2011-03-25 03:04:51 EDT
udev-166-2.fc15, libconcord-0.23-5.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Adam Williamson 2011-04-26 00:12:27 EDT
Seems like the fix for this isn't quite complete. With libconcord-0.23-5 and udev-167-4 it still doesn't work as user until I do:

setfacl -m o:rw /dev/bus/usb/xxx/xxx (where xxx/xxx is the particular USB device the remote showed up as).

without that command it shows up as 

# file: 004
# owner: root
# group: dialout
user::rw-
group::rw-
other::---

and concordance can't detect the remote as regular user, but can as root.

so I think the udev hookup with ID_REMOTE_CONTROL isn't working right.
Comment 24 Fedora Admin XMLRPC Client 2011-10-20 12:09:36 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 25 Fedora Admin XMLRPC Client 2011-10-20 12:11:44 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 26 Fedora Admin XMLRPC Client 2011-10-20 12:13:32 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 27 Fedora Admin XMLRPC Client 2011-10-20 12:17:58 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 28 Harald Hoyer 2011-10-21 05:58:56 EDT
$ fgrep -r  REMOTE  /lib/udev/rules.d/
/lib/udev/rules.d/70-uaccess.rules:ENV{ID_REMOTE_CONTROL}=="1", TAG+="uaccess"
Comment 29 Adam Williamson 2011-10-21 11:56:37 EDT
I'm not sure what you mean by that.

I know we put in the proposed Stuff, but as per comment #23, I tested after that, and it still didn't seem to work.
Comment 30 Adam Williamson 2012-01-16 17:52:51 EST
Well I think I figured one thing out here: we should be using the policykit or consolekit-style udev rules, not the default 'original' style ones, in libconcord. I'm rebuilding it with consolekit support to see if that improves things.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 31 Kay Sievers 2012-01-16 18:09:53 EST
Just ID_REMOTE_CONTROL should be set, nothing else.

PolicyKit is not involved here.

ConsoleKit is no longer supported, and will probably not be in the default
install of Fedora 17.
Comment 32 Adam Williamson 2012-01-16 18:37:36 EST
okay...so it's not that simple.

the policykit / consolekit support options (possibly?) require hal. when hal got killed, we switched to using the generic udev support on the recommendation of notting, as the easiest way to get around the hal removal. however, now I look at it closely, the generic hal option isn't as good as the policykit / consolekit support.

the policykit / consolekit options give the console user access to the remote control, which is nice and simple and requires no configuration. The generic udev support only gives members of the 'dialout' group access to the device, which is kind of a hack and requires you to add your user to the dialout device.

additionally it's now broken, I think, because it uses SYSFS not ATTR, which is why it's not working at all right now.

so I can just patch it to use ATTR not SYSFS for the generic udev support, or we could try and make the ck / pk support options (or at least one of them) work without hal, and get a better result.

I'll try doing the first one of those, for now. CCing notting.
Comment 33 Adam Williamson 2012-01-16 18:37:56 EST
kay: i'm talking about on the libconcord side in my comments, apologies if that's not clear.
Comment 34 Adam Williamson 2012-01-16 18:41:07 EST
"generic hal option isn't as good as the policykit / consolekit support" should of course read "generic udev option isn't as good as the policykit / consolekit support". Sigh.
Comment 35 Kay Sievers 2012-01-16 18:55:20 EST
I don't think anything besides:
  SUBSYSTEM="usb" ATTR{idVendor}=="xxx", ATTR{idProduct}=="xxx", \
    ENV{ID_REMOTE_CONTROL}="1"
should be done.

No symlink, no group assignment, no policykit, no consolekit, no hal support
should be applied.

Udev rules will pick up ID_REMOTE_CONTROL, tag the device with a marker that
locally logged-in users should get access to the device, and systemd-logind
(at user login) or systemd-uacess (at device hotplug) will find these udev
tags and apply the ACL to the device node accordingly.
Comment 36 Adam Williamson 2012-01-16 19:15:10 EST
now we've discussed it in IRC, I agree that's probably correct.

what I wanted to make sure of is that we don't grant access *more widely* than upstream wants. Upstream hasn't touched this stuff since 2-3 years ago, so you have to keep the udev/hal of 2009 in mind when looking at what upstream's udev rule generator thingy does, not the udev/hal of now.

so what upstream really wanted back then was apparently not really possible with pure udev, so they implemented this hack of abusing the 'dialout' group so that you had to be in it to access the device. then they found they could implement finer control using hal/policykit or hal/consolekit, so they added that as an option. obviously, those two paths reflect upstream's best intentions.

it seems like if you look at the hal/policykit policy they wrote, it does this:

      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>

and IIRC, hal's definition of 'active' or 'inactive' users matches quite closely which users udev will now grant permissions to if we just use the line you recommend in comment #35. so I think it's good to just patch the 'generic udev' path of libconcord's rule generator to that, and submit it upstream. they may want to add it as a fourth 'modern udev' option, or something, but that's no big deal.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 Fedora Update System 2012-01-19 14:00:01 EST
libconcord-0.23-9.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/libconcord-0.23-9.fc15
Comment 38 Fedora Update System 2012-01-19 14:01:49 EST
libconcord-0.23-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/libconcord-0.23-9.fc16
Comment 39 Fedora Update System 2012-01-21 16:47:59 EST
Package libconcord-0.23-9.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libconcord-0.23-9.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0717/libconcord-0.23-9.fc15
then log in and leave karma (feedback).
Comment 40 Fedora Update System 2012-01-24 14:56:46 EST
libconcord-0.23-9.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 41 Fedora Update System 2012-01-24 14:57:21 EST
libconcord-0.23-9.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.