Bug 859244

Is there another group that should be used, or should the GROUP directive be dropped entirely?  Or that whole line?

The group directory should be dropped entirely and the rule fixed. 

I have asked Kay to give a bit more detail ( sample ) what he means on the bug I mentioned there in the meantime you can add this as a workaround ( as is being done in the libftdi.spec ) 

"%pre
getent group plugdev >/dev/null || groupadd -r plugdev
exit 0"

To the spec file then just remove it when the actual fix for the udev rule is ready.

Ok, I'll get this out.  Let me know when "fixed" becomes specifically defined.

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

argyllcms-1.4.0-5.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/argyllcms-1.4.0-5.fc18

argyllcms-1.4.0-4.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/argyllcms-1.4.0-4.fc17

Package argyllcms-1.4.0-5.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing argyllcms-1.4.0-5.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14574/argyllcms-1.4.0-5.fc18
then log in and leave karma (feedback).

Once again - it's fairly pointless having such a discussion without
feeding it upstream - you're then stuck with re-evaluating and
merging such changes for every ArgyllCMS release.

plugdev is used as a fallback for wider range of systems than just
Redhat, so you need to marshal some better arguments as to why and
how it can be done away with if there is truly a problem (ie.
isn't Fedora going to end up using ACL_MANAGE ?)

Note the existing instructions for dealing with the lack a a plugdev:
<http://www.argyllcms.com/doc/Installing_Linux.html>

(In reply to comment #8)
> Once again - it's fairly pointless having such a discussion without
> feeding it upstream - you're then stuck with re-evaluating and
> merging such changes for every ArgyllCMS release.

Arguably upstreams that are dependant and or use other upstreams should always follow what that upstream is doing and recommends ( in this case udev ) and downstreams work around those changes. Not the other way around as in downstream having to patch upstream to keep themselves and upstream up to date in relevance other upstreams changes from my pov ( At least that comes more logically to me ).
 
> plugdev is used as a fallback for wider range of systems than just
> Redhat,

You need to be a bit more specific to which systems you are referring to.  

> so you need to marshal some better arguments as to why and
> how it can be done away with if there is truly a problem (ie.
> isn't Fedora going to end up using ACL_MANAGE 

See comment 4 on bug 815093 which in essence just explains that the old udev way of doing things was kind of hacky, abused system group(s) and requiring you
to add user account(s) to it manually. ( which is what the "workaround" in comment 2 is exactly doing )

In anycase I'm no udev expert but I would think that color measurement devices should receive it's own ID and be added to 70-uaccess.rules as in something like ENV{ID_COLOR_MEASUREMENT_DEVICE}=="1", TAG+="uaccess" and 55-Argyll.rules and 69-cd-sensors.rules merged and adjusted into a single ruleset for both of them to use ( and every application that work with color measurement devices ), since to me those rules should be identical more or less ( colord has a daemon which is probably why it's being added to the colord group ) but Kay can probably comment on what is the proper cause of action here and if application should be conducting ( needless ) fragmentation in this area. 

In the meantime you ( or Jon )could have a look at 69-cd-sensors.rules and adjust yours according to what Richard has done there.

Btw encse yo missed it consolekit is no longer actively being maintained ( it has been replaced with systemd-loginctl [1] ) so you can probably drop the reference to it in your udev rule(s) and the udev sources got merged with systemd systemd source tree a while back

1. http://www.freedesktop.org/software/systemd/man/loginctl.html
2. http://www.freedesktop.org/software/systemd/man/udev.html

> Arguably upstreams that are dependant and or use other upstreams
> should always follow what that upstream is doing and recommends ( in
> this case udev ) and downstreams work around those changes. Not the
> other way around as in downstream having to patch upstream to keep
> themselves and upstream up to date in relevance other upstreams
> changes from my pov ( At least that comes more logically to me ).

I'm subscribed to the udev mailing list, and have seen nothing that
covers such changes. In any case, I'm leery of anything stated about
udev - I've been well and truly lead down the garden path by
whatever is seen as the latest trendy change for changes sake
(ie. PolicyKit + Hal), and I'm now only interested in what will
works across a range of real systems.

> You need to be a bit more specific to which systems you are referring to.

I don't think I do - ACL_MANAGE etc. is relatively new. Older systems
don't use it, so a group is a reasonably standard UNIX mechanism
for covering such permissions, and not subject to the sort of
API churn that udev has a history of. "plugdev" was merely picked
as a convenient name that has been used for a very similar and
compatible purpose. I could have chosen "argyll" as a group,
but decided to at least leverage some history there.

> See comment 4 on bug 815093 which in essence just explains that the
> old udev way of doing things was kind of hacky, abused system group(s)
> and requiring you
> to add user account(s) to it manually. ( which is what the
> "workaround" in comment 2 is exactly doing )

This comment seems to be perfectly consistent with the reason that
55-Argyll.rules us written as it is - it uses ACL_MANAGE if
available, and falls back to a group if it is not available.

> In anycase I'm no udev expert but I would think that color measurement
> devices should receive it's own ID and be added to 70-uaccess.rules as
> in something like ENV{ID_COLOR_MEASUREMENT_DEVICE}=="1",
> TAG+="uaccess" and 55-Argyll.rules and 69-cd-sensors.rules merged and
> adjusted into a single ruleset for both of them to use ( and every
> application that work with color measurement devices ), since to me
> those rules should be identical more or less ( colord has a daemon
> which is probably why it's being added to the colord group ) but Kay
> can probably comment on what is the proper cause of action here and if
> application should be conducting ( needless ) fragmentation in this area.

ArgyllCMS is not tied to Redhat, nor even Linux, and is an independent
applications, that is released on its own schedule. New color instruments
are being added all the time, so the end user needs a simple a way of
possible to update the udev rules to enable the new devices, when they
install an ArgyllCMS update.  That this is awkward and less
convenient on Linux than other operating systems, is part of
the reason why Linux on the desktop has never taken off. I certainly don't
wish to be tied to what other applications with much narrower platform
scope such as colord are doing, so a separate 55-Argyll.rules that is
deliberately designed to work on a wide range of linux distributions
is as it should be. No, you can't assume users get Argyll from a distro
repository, since such repositories have a history of adding unwelcome
changes to it, and being too platform dependent.

> In the meantime you ( or Jon )could have a look at 69-cd-sensors.rules
> and adjust yours according to what Richard has done there.

Richard has done his own thing, and much of it it's tied to what colord
needs. In the Redhat world what he's done makes perfect sense. Not all
systems use colord though - they use ArgyllCMS as is, or use Oyranos.

> Btw encse yo missed it consolekit is no longer actively being
> maintained ( it has been replaced with systemd-loginctl [1] ) so you
> can probably drop the reference to it in your udev rule(s) and the
> udev sources got merged with systemd systemd source tree a while back

Fabulous - more API churn!
[And I note that this merger is far from completely accepted amongst
 distributions.]

I'll remove the test for console kit in the next release.

(In reply to comment #10)
> > Arguably upstreams that are dependant and or use other upstreams
> > should always follow what that upstream is doing and recommends ( in
> > this case udev ) and downstreams work around those changes. Not the
> > other way around as in downstream having to patch upstream to keep
> > themselves and upstream up to date in relevance other upstreams
> > changes from my pov ( At least that comes more logically to me ).
> 
> I'm subscribed to the udev mailing list, and have seen nothing that
> covers such changes. In any case, I'm leery of anything stated about
> udev - I've been well and truly lead down the garden path by
> whatever is seen as the latest trendy change for changes sake
> (ie. PolicyKit + Hal), and I'm now only interested in what will
> works across a range of real systems.

The announcement can be found here [1]

> > You need to be a bit more specific to which systems you are referring to.
> 
> I don't think I do - ACL_MANAGE etc. is relatively new. Older systems
> don't use it, so a group is a reasonably standard UNIX mechanism
> for covering such permissions, and not subject to the sort of
> API churn that udev has a history of. "plugdev" was merely picked
> as a convenient name that has been used for a very similar and
> compatible purpose. I could have chosen "argyll" as a group,
> but decided to at least leverage some history there.

As far as I know every major distribution except Ubuntu ( which has a tendency to fork it self in a corner one way or another ) is either defaulting to or is shipping systemd along with as an init replacement for their distribution so which system does indeed matter ( Atleast for the future that is ).

Trying to support what all ca 500 linux distribution out there to me is an unrealistic goal + as of udev release 182 the udev-acl tool is no longer being provided which breaks your test there and is affecting F17+ and any other distro that ships udev 182 or newer  
 
> > See comment 4 on bug 815093 which in essence just explains that the
> > old udev way of doing things was kind of hacky, abused system group(s)
> > and requiring you
> > to add user account(s) to it manually. ( which is what the
> > "workaround" in comment 2 is exactly doing )
> 
> This comment seems to be perfectly consistent with the reason that
> 55-Argyll.rules us written as it is - it uses ACL_MANAGE if
> available, and falls back to a group if it is not available.

As I mentioned before udev-acl tool is no longer provided as of udev release 182 [2] the test case for it will always fail and try to fallback on the non existing group

> > In anycase I'm no udev expert but I would think that color measurement
> > devices should receive it's own ID and be added to 70-uaccess.rules as
> > in something like ENV{ID_COLOR_MEASUREMENT_DEVICE}=="1",
> > TAG+="uaccess" and 55-Argyll.rules and 69-cd-sensors.rules merged and
> > adjusted into a single ruleset for both of them to use ( and every
> > application that work with color measurement devices ), since to me
> > those rules should be identical more or less ( colord has a daemon
> > which is probably why it's being added to the colord group ) but Kay
> > can probably comment on what is the proper cause of action here and if
> > application should be conducting ( needless ) fragmentation in this area.
> 
> ArgyllCMS is not tied to Redhat, nor even Linux, and is an independent
> applications, that is released on its own schedule. New color instruments
> are being added all the time, so the end user needs a simple a way of
> possible to update the udev rules to enable the new devices, when they
> install an ArgyllCMS update.  That this is awkward and less
> convenient on Linux than other operating systems, is part of
> the reason why Linux on the desktop has never taken off. I certainly don't
> wish to be tied to what other applications with much narrower platform
> scope such as colord are doing, so a separate 55-Argyll.rules that is
> deliberately designed to work on a wide range of linux distributions
> is as it should be. No, you can't assume users get Argyll from a distro
> repository, since such repositories have a history of adding unwelcome
> changes to it, and being too platform dependent.

How is this process being handled on other OS like for example in OS-X?

> > In the meantime you ( or Jon )could have a look at 69-cd-sensors.rules
> > and adjust yours according to what Richard has done there.
> 
> Richard has done his own thing, and much of it it's tied to what colord
> needs. In the Redhat world what he's done makes perfect sense. Not all
> systems use colord though - they use ArgyllCMS as is, or use Oyranos.

But the supported color management devices still remain the same for all of these right?  

1.http://thread.gmane.org/gmane.linux.hotplug.devel/17392
2.http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=NEWS;hb=a3a304ddc090db59cb3be0dcbf1c0d83fe84c33a

Jon the proper way to fix this is to revert the workaround and carry a local patch and follow what other distributions are doing like for example opensuse [1]
since upstream cant drop those rules

1. https://build.opensuse.org/package/view_file?file=argyllcms-1.3.0-udev151.patch&package=argyllcms&project=multimedia%3Aphoto&rev=60ca08ca9e2425de1ef13a9b0f9a27a4

Does that apply against what we ship?

What's being done in that patch certainly applies to to us atleast F17+ not sure if udev-acl has been removed in F16 for that "TEST" section to work which is being removed there. I have not tested applying that patch to our sources if that's what you are referring but if it does not our patch should look the same as what other distributions are doing so we can all drop it if/when upstream decides it's time to drop those rules.

Richard, would you care to weigh in here?

That sounds like the right thing. We do not want "plugdev" in Fedora. It's
mainly an Ubuntuism, that is misguiding, too static, and insecure.

Fedora fully dynamically grants access to devices based on the state of
the user's login session and the physical seat configuration. We do not
ever put users in groups to grant ordinary users access to hot-pluggable
devices.

Static system groups are inflexible and insecure in the sense that e.g.
ssh-login users must not be able to log into a machine and listen to the microphone or the camera or any other device that is associated with a
physical seat.
It would be unlikely to cause any harm for a color management device,
but the general rule that we do not want to support any static group like:
"the users who can use pluggable devices" still applies, and it it the
wrong thing to introduce "plugdev".

The right thing for Fedora is to patch out all ACL_MANAGE, udev-acl,
ConsoleKit and plugdev group stuff from the upstream packages in the
packaging step. These fallbacks are not expected or wanted in Fedora.

Upstream should note that blindly using unknown system groups in udev
rules can cause systems to be unable to boot up, because the group is
unresolvable. This is a major issue and nothing that is about just
"making things work", it actually can cause quite the opposite of it.

bugzilla wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=859244
> 
> --- Comment #11 from Jóhann B. Guðmundsson <johannbg> ---
> (In reply to comment #10)
>>> Arguably upstreams that are dependant and or use other upstreams
>>> should always follow what that upstream is doing and recommends ( in
>>> this case udev ) and downstreams work around those changes. Not the
>>> other way around as in downstream having to patch upstream to keep
>>> themselves and upstream up to date in relevance other upstreams
>>> changes from my pov ( At least that comes more logically to me ).
>>
>> I'm subscribed to the udev mailing list, and have seen nothing that
>> covers such changes. In any case, I'm leery of anything stated about
>> udev - I've been well and truly lead down the garden path by
>> whatever is seen as the latest trendy change for changes sake
>> (ie. PolicyKit + Hal), and I'm now only interested in what will
>> works across a range of real systems.
> 
> The announcement can be found here [1]

I see no mention of the plugdev group in this announcement.

My aim is to write and support an application, not to scour
the universe tracking minute changes to various versions of
an operating system.

The best I can do is investigate when something breaks due to
API churn, fix it in the most robust and backwards compatible
way I can identify, test as best I can, and then go back to real
work and wait for future breakage. (Note that systems that
want to encourage a rich, diverse and vibrant application
ecosystem try and minimise API breakage.) 

> As far as I know every major distribution except Ubuntu ( which has a tendency
> to fork it self in a corner one way or another ) is either defaulting to or is
> shipping systemd along with as an init replacement for their distribution so
> which system does indeed matter ( Atleast for the future that is ).

Hmm. I can't seem to locate it on Fedora 8 development box,
so I guess that you mean just the latest releases of major
distributions have systemd. Unfortunately not everyone
is in a position to upgrade their operating system to
the latest release when it comes out (possibly involving
upgrading hardware etc.), and then spend time getting
their system working again. So it's necessary to allow for
backwards compatibility - just like many systems try and
make sure they don't break existing applications, good
application try and make sure that they don't stop 
working when new versions are installed on older systems.

> Trying to support what all ca 500 linux distribution out there to me is an
> unrealistic goal + as of udev release 182 the udev-acl tool is no longer being
> provided which breaks your test there and is affecting F17+ and any other
> distro that ships udev 182 or newer  

It's not at all unrealistic if there is a core API. Trying to
support them all by each one tweaking and compiling every application
for each of them, is an unrealistic expectation. Which is why the
distro model is broken. In fact it encourages API churn, poor planning,
and ad-hoc API changes, under the assumption that all the applications
that get broken can be fixed, because all the applications
are part of the distribution. The result is few applications that
are distributed any other way.
 
> As I mentioned before udev-acl tool is no longer provided as of udev release
> 182 [2] the test case for it will always fail and try to fallback on the non
> existing group

I see no mention of ACL_MANAGE in your reference. In fact
I can see no mention of udev-acl tool being deprecated in
your reference, merely that it is being packaged in a different
way. Or are you meaning that the TEST=="/lib/udev/udev-acl"
is no longer valid ?

Looking at the current git 70-acl.rules it seems that
ACL_MANAGE is not deprecated, and uses the test
TEST=="/var/run/ConsoleKit/database". So I guess
that is the test that should remain in 55-Argyll.rules for
using ACL_MANAGE.

It's not evident if there is any way of testing for
the existence of the ENV{COLOR_MEASUREMENT_DEVICE}=="*?", ENV{ACL_MANAGE}="1"
line in 70-acl.rules though, which is what would be necessary to
modify 55-Argyll.rules to be able to reliably use COLOR_MEASUREMENT_DEVICE
as a first choice.

> How is this process being handled on other OS like for example in OS-X?

Other operating systems are generally simpler. For HID devices on MSWin,
nothing needs to be done - plug in the device and the application
can access it. For non HID devices it is more complex, but
essentially there needs to be a .inf file that tells the OS
what kernel driver to use, and the application can then access it.
There are no device permission issues. And this applies from Win2K though
to Win8

For OS X, nothing has to be done. Plug the instrument in and
the application can access it. There are no device permission issues.
This applies for OS X 10.3 - 10.8

i.e. Because both of these OS's are more person oriented rather
than server oriented, the default policy is that someone having
physical access to the machine has permission to run an application
on the console that can access such a device.

> But the supported color management devices still remain the same for all of
> these right?  

Yes, but the support is application dependent, so it's tied to the
application release, not the system release. ie., both the
system and applications need a mechanism for enabling
color instruments independently. So given the arrangement of
udev, there needs to be room for independent .rules files
being installed with an application update. And backwards
compatibility requirements mean not relying on any system
changes that are recent (ie. say less than 5 years old).

>--- Comment #16 from Kay Sievers <kay> ---
> That sounds like the right thing. We do not want "plugdev" in Fedora. It's
> mainly an Ubuntuism, that is misguiding, too static, and insecure.

Be that as it may, older systems do not have any other widely
available option, hence its use as a fallback. It provides
a means for a user to get an instrument going when ACL_MANAGE
is not supported.

> Fedora fully dynamically grants access to devices based on the state of
> the user's login session and the physical seat configuration. We do not
> ever put users in groups to grant ordinary users access to hot-pluggable
> devices.

It may do now, but it did things differently in the past. And that's
the issue here - dealing with backwards and other distribution compatibility.

> The right thing for Fedora is to patch out all ACL_MANAGE, udev-acl,
> ConsoleKit and plugdev group stuff from the upstream packages in the
> packaging step. These fallbacks are not expected or wanted in Fedora.

That's simply an unacceptable churn in the Application Programming Interface
in my view. udev .rules files are part of the API, because they need to be set
for applications to access user USB devices, due to the conservative
permission policy adopted by Linux. So changes in the way
.rules files should work need to worked out with some care
and an eye for compatibility with existing applications and
backward compatibility in older systems and other distributions.

The best way forward is to at least provide some versioning or
preferably capability mechanism, so that backwards compatible
.rules files can be crafted that shift to new mechanisms when
available.

> Upstream should note that blindly using unknown system groups in udev
> rules can cause systems to be unable to boot up, because the group is
> unresolvable. This is a major issue and nothing that is about just
> "making things work", it actually can cause quite the opposite of it.

Sounds poor if a system fails to boot for this reason, particularly
one involving a non-boot critical user device such as color instrument.
Note that groups are a very suitable fallback given their wide support
amongst UNIX like systems. My previous option was simply
changing permissions on the device directly. I guess that could
be reverted to, although various people complained about it.

First, upstream is not in charge of providing something that matches Fedora's
need. That can all be done in the packaging.

Second, only ENV{ID_COLOR_MEASUREMENT_DEVICE}=="1" is needed, and that works
for quite some years. When upstream like to fiddle with low-level knobs of the
Base OS, which change depending on the need of the overall architecture, it's
fine, they can do that. But they should also not be surprised that these games
end up in breakage. We do not want this in Fedora. The udev-acl tool,
ACL_MANAGE, ConsoleKit have never been any sort of API to be used directly by
tools, only the flags for the classes of devices are the API, the rest is part
of the system/distro policy which must not be touched by tools.

Third, a single wrong udev rule can render the entire system
un-bootable. Therefore, installing udev rules comes with a certain
responsibility; such an issue can not be ignored for that long. Upstream
seem not to even understand the problem it is causing, by naively playing
around with lowest-level Base OS properties. Jon, please just patch out all
upstream udev mis-use, it can not work reliably on Fedora, and it will cause serious bugs.

bugzilla wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=859244
> 
> --- Comment #19 from Kay Sievers <kay> --- First,
> upstream is not in charge of providing something that matches
> Fedora's need. That can all be done in the packaging.

Please explain how. I've been looking into these USB permission problems for many years, and no-one pointed to anything as simple as
"packaging" - on the contrary, all advice pointed to the need to udev
.rules files, and prior to that, hotplug usermap files.

> Second, only ENV{ID_COLOR_MEASUREMENT_DEVICE}=="1" is needed, and
> that works for quite some years. When upstream like to fiddle with
> low-level knobs of the Base OS, which

It's only been around since colord has been part of Fedora,
and hence cannot be relied upon for older systems or those
without colord.

> change depending on the need of the overall architecture, it's
> fine, they can do that. But they should also not be surprised that
> these games end up in breakage. We do not

This is not some "game" - it's simply trying to get things to
work in the best possible manner.

> want this in Fedora. The udev-acl tool, ACL_MANAGE, ConsoleKit have
> never been any sort of API to be used directly by tools, only the
> flags for the classes of devices are the API, the rest is part of
> the system/distro policy which must not be touched by tools.

If the only way that an application can enable permissions to access
a USB device is to install a udev .rules file, then these are indeed
part of the application programming interface, and it is simply
wishful thinking to claim that they are not. If I am mistaken (and
there is some other standard mechanism to fix the USB permissions
problem that everyone has overlooked for the past 10 years), and
please point it out. It would be a relief not to have to worry
about udev.

> Third, a single wrong udev rule can render the entire system
> un-bootable. Therefore, installing udev rules comes with a certain
> responsibility; such an issue can not be ignored for that long.
> Upstream seem not to even understand the problem it is causing, by
> naively playing around with lowest-level Base OS properties.

That is the recommended mechanism provided to allow applications to
fix USB device permission problems. If that exposed API is "lowlevel",
and can easily render a system un-bootable, then it seem like very poor
API design, and I suggest an effort to correct it or replace it with
something safer.

> Jon, please just patch out all upstream udev mis-use, it can not
> work reliably on Fedora, and it will cause serious bugs.

Sounds like you'll be patching it into the indefinite future then,
since it seems you cannot be bothered to understand and address a
very real and long standing Linux application problem.

I've reverted the "groupadd -r plugdev" fix in the spec file as it's the wrong fix for Fedora. It might be correct upstream (not going to get in that argument) but for Fedora the fix is to just rely on ENV{COLOR_MEASUREMENT_DEVICE}="1" magically doing the right thing. I'll push a new package tomorrow with the fix which involves one line being removed from 55-Argyll.rules as a distro-patch. If the distro relies on colord (which Fedora does) then we can remove the 55-Argyll.rules file completely, although it certainly makes sense to ship upstream.

Richard.

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

argyllcms-1.4.0-6.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/argyllcms-1.4.0-6.fc18

Package argyllcms-1.4.0-6.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing argyllcms-1.4.0-6.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16950/argyllcms-1.4.0-6.fc18
then log in and leave karma (feedback).

argyllcms-1.4.0-5.fc18 has been pushed to the Fedora 18 obsolete repository.  If problems still persist, please make note of it in this bug report.