On Sun, 2012-03-11 at 13:13 -0700, Phil Dibowitz wrote: > On 01/16/2012 07:01 PM, Adam Williamson wrote: > > I'm attaching a patch which updates the udev rule generation stuff in > > libconcord. It adds a fourth option to gen_udev_support (because, you > > know, it wasn't messy enough already). > > > > Modern udev - well, udev since June 2009 - can control access to device > > nodes via ACLs, avoiding the need for anything external (hal, policykit, > > consolekit, whatever) for controlling access. The existing 'generic > > udev' support is kind of hacky, abusing a system group and requiring you > > to add user accounts to it manually. The existing 'policykit' and > > 'consolekit' support (which should really be named hal/policykit and > > hal/consolekit) rely on hal and are therefore useless on modern > > distributions where hal is being nuked with a vengeance. I doubt the > > policykit stuff would work with pk 1.0 either, though I haven't checked > > (can't check, no hal in fedora). Using udev-acl is very simple and > > elegant and avoids all that complexity and reliance on dead/dying > > interfaces. > > Yeah, I haven't kept up-to-date and for a variety of reasons, I'm often using > root on my harmony (because a lot of my dev scripts still use 'sudo' from the > days before I ever thought of udev support). > > This is awesome. > > > This will only work with udev builds that have this commit in them: > > > > https://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=5e199245f2d2fd03c2586a7f1140300b073a4abe > > So this adds a ID_REMOTE_CONTROL bit which can possibly be set in a udev rule, > right? And if so, adds some udev-acl tag > > > SUBSYSTEM=="usb", ATTR{idVendor}=="046d", > > ATTR{idProduct}=="c1[1-4][0-9a-f]", ENV{ID_REMOTE_CONTROL}="1" > > OK, I have to say, I to say, I'm not sure I get this. It... is a matching > line. But I don't see an action. I mean, it sets ID_REMOTE_CONTROL, but > like... what does something with that? I don't see where that defines normal > users can use it or what mode the device should be or... anything. > > Oh - at the bottom of the 70-udev-acl.rules it checks if consolekit is around > and then runs udev-acl which I guess is the magic there. OK, cool.
Right, udev has the magic now, rather than the libconcord rules file. Well, in Fedora 17 at least it's now in systemd - /usr/lib/udev/rules.d/70-uaccess.rules . That's the latest shiny, I guess. But the 'new udev' in the patch should work for any distro with a udev that a) has acl support and b) has the ID_REMOTE_CONTROL tag. > OK, patch looks good, assuming my understanding is correct. > > A few questions... > > 1. are there any modern distros using consolekit or policykit anymore? If not, > lets just drop that stuff. Well...everyone still uses PolicyKit, AFAIK, and everyone but Fedora still uses ConsoleKit (and we're only dropping it in F17, which isn't out yet). But the thing about those options are that they're really using *hal*, the CK / PK usage is via hal. Still, Fedora dropped hal I think in F16, so that's a pretty recent thing. I think it probably makes sense to keep those options around (though of course I'm not the one who gets to maintain them). Fast-moving distros like Fedora, OpenSUSE, Ubuntu should either already have support for the udev-acl way of doing things or should get it soon. But slower distros like Debian, RHEL and Ubuntu LTS are still around, and they may well not get a new enough udev until their next major releases, and people will still be using older releases. It's a question of how much you care about slower-moving distros, I guess. > 2. If the new udev method doesn't depend on anything, why does it test for > consolekit stuff in 70-udev-acl.rules? So, AFAICT here what's going on is systemd. If you have systemd, it handles the udev-acl stuff. If you don't, you need ConsoleKit to do it. That's what https://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=b618e9957b2bd8a4484368620b71ca16fef0c9e6 suggests, anyway. So on Fedora it's true to say that udev-acl functionality doesn't need anything outside of udev and systemd. On non-systemd distros, I guess ConsoleKit is needed for this to work. So, since it looks like the setup is somewhat different on Fedora / non-Fedora (systemd / non-systemd, but at the moment they map pretty closely...), I guess it'd be good if people running distros other than Fedora could check my stuff and see if it works...just make sure you have a new enough udev (as explained in the docs in the patch). I know it definitely works on Fedora (I re-programmed my Harmony just a couple of days ago) but I have not tested on any other distro. > > plus a line for the one device with the old vendor ID. This would > > obviate the need for the 'neat trick' entirely. This is also a > > suggestion from Kay, so credit to him. I also have a trivial patch to > > fix compilation with GCC 4.7. > > Send it on! The GCC 4.7 patch is: http://pkgs.fedoraproject.org/gitweb/?p=libconcord.git;a=blob;f=libconcord-0.23-gcc47.patch;h=41a58d4f19c2c2612af0a594b2e437380700a166;hb=HEAD very trivial :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
