On Wed, Jun 9, 2010 at 19:01, Julien BLACHE <jblache@xxxxxxxxxx> wrote: > I am wondering how one is supposed to integrate/interact with udev-acl > outside of its dedicated rules file, as using ACL_MANAGE outside this > file is strictly forbidden. > > Setting dedicated variables via other rules to have them checked and > acted upon by the dedicated udev-acl rules seems suboptimal in more than > one way :/ > > So, what's the long-term plan on this? I've discussed this with Marco > d'Itri, our udev maintainer, and a couple other Debian developers and we > all wonder how this is supposed to work on the long term. Can someone > shed light on this for us, please? There is no real long-term plan to explain. It's just that stuff is moving all the time. There might be upcoming changes in ConsoleKit which require changes again. I'm not really involved in this, don't know the details, but I know people talking about new stuff. We need to split classification from policy here, to be able to plug-in a possible finer-grained policy that's based on more ConsoleKit properties than "local". That's why the flags in udev flags to mark devices should not be used directly. > [SANE upstream hat on] > Second point in this mail, the rules used for SCSI scanners by udev-acl > are too broad as they are today; they may match SCSI devices that aren't > scanners (like tape libraries and other SCSI equipment reporting a > control interface with a SCSI type of "Processor", for instance - this > has been seen before). > > Instead of duplicating the rules from libsane, I propose to also set > libsane_matched for SCSI scanners starting with the next SANE release > (whenever that happens, and I'd encourage distributors to patch the SANE > rules right now already). > > Would that be OK with you? Sure, sounds good to me. Just let us know, when this is generally available in a released version, and we can remove the rule from udev. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
