Questions on udev-acl rules, ACL_MANAGE + bug report

Questions on udev-acl rules, ACL_MANAGE + bug report

[Julien BLACHE]

Hi,

[Please Cc: me on replies, I'm not subscribed]

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?

[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?

Thanks,

JB.

-- 
 Julien BLACHE <jblache@debian.org>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer        |       <http://www.debian.org>
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 

Re: Questions on udev-acl rules, ACL_MANAGE + bug report

[Kay Sievers]

On Wed, Jun 9, 2010 at 19:01, Julien BLACHE <jblache@debian.org> 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

Re: Questions on udev-acl rules, ACL_MANAGE + bug report

[Julien BLACHE]

Kay Sievers <kay.sievers@vrfy.org> wrote:

Hi,

[udev-acl]
> 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

It's a bit puzzling to read that, to be honest. "We're going to break
things, deal with it" is becoming a bit old.

> know the details, but I know people talking about new stuff.

Could the above "people" please shed some light on this?

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

I'll do. In the meantime, distributors should patch this up themselves,
as we're probably months away from the next SANE release.

JB.

-- 
 Julien BLACHE <jblache@debian.org>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer        |       <http://www.debian.org>
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 

Re: Questions on udev-acl rules, ACL_MANAGE + bug report

[Kay Sievers]

On Wed, Jun 16, 2010 at 06:49, Julien BLACHE <jblache@debian.org> wrote:
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>> 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
>
> It's a bit puzzling to read that, to be honest. "We're going to break
> things, deal with it" is becoming a bit old.

I think it's pretty clear: Don't use udev's low-level stuff managing
ACLs directly in packages. There is nothing else that breaks.

This is all very new stuff, and new stuff changes until the pain to
change is larger than the gain of the change. That point is surely not
reached today.

It's not different from any other new stuff that has a certain grade
of complexity -- just don't use it if you can't cope with possible
changes -- because they will very likely happen.

>> know the details, but I know people talking about new stuff.
>
> Could the above "people" please shed some light on this?

You can ask them. It's the people who work on the multi-seat stuff.
But I doubt they can outline a plan more detailed than: don't use the
udev low-level stuff directly in packages. :)

Thanks,
Kay