Bug 559412

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

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.

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?

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.

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 ?

harald: ping?

*** Bug 622674 has been marked as a duplicate of this bug. ***

still valid up to f15, of course.

(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.

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.

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?

ok, then I will have to add to /lib/udev/rules.d/70-acl.rules

ENV{ID_PROGRAMMABLE_REMOTE}=="1", TAG+="udev-acl"

OK, I'm pushing builds with that change through right now. Rawhide is pushed, F15 is going, and I will also do F14.

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.

(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.

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.

I've pushed libconcord builds with ID_REMOTE_CONTROL now.

harald: ping? can you push an updated udev to koji, please? I'd really like to push the fixes together.

f14: http://koji.fedoraproject.org/koji/taskinfo?taskID=2936078
f15: http://koji.fedoraproject.org/koji/taskinfo?taskID=2936030

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

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

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.

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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

$ fgrep -r  REMOTE  /lib/udev/rules.d/
/lib/udev/rules.d/70-uaccess.rules:ENV{ID_REMOTE_CONTROL}=="1", TAG+="uaccess"

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.

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

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.

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.

kay: i'm talking about on the libconcord side in my comments, apologies if that's not clear.

"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.

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.

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

libconcord-0.23-9.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/libconcord-0.23-9.fc15

libconcord-0.23-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/libconcord-0.23-9.fc16

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).

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.

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.