udev rules for raw1394 video1394 not working

Looks like we're missing a "-" in the video1394 rules (and probably dv1394)

Note that the raw rule is not supposed to match, which is why it explicitly checks SUBSYSTEM. /dev/raw1394 should be where it is.

Added the missing '-' to the 1394 rules.
Right, the "raw" stuff is for block devices, not for firewire.

Btw, isn't the old ieee1394 stack fully replaced by the "firewire" drivers?

After adding the "-" in the rule, the device video1394 is now created correctly.

But as I compared the current udev rules with the previous version (intrepid), there seems to be a rule missing for firewire devices:

intrepid:
KERNEL=="raw1394", GROUP="disk"
KERNEL=="dv1394*", GROUP="video"
KERNEL=="video1394*", GROUP="video"

jaunty:
KERNEL=="dv1394[0-9]*", NAME="dv1394/%n", GROUP="video"
KERNEL=="video1394[0-9]*", NAME="video1394/%n", GROUP="video"

I suppose the rule:
KERNEL=="raw1394", GROUP="disk"

should be added as well.

> I suppose the rule:
> KERNEL=="raw1394", GROUP="disk"

I think, that has been removed for security reasons, because you could loopback the cable and the "video" user could get access the random hardware through the firewire interface.

On Tue, 2009-05-05 at 11:52 +0000, C-x-s wrote:

> After adding the "-" in the rule, the device video1394 is now created
> correctly.
>
> But as I compared the current udev rules with the previous version
> (intrepid), there seems to be a rule missing for firewire devices:
>
> intrepid:
> KERNEL=="raw1394", GROUP="disk"
> KERNEL=="dv1394*", GROUP="video"
> KERNEL=="video1394*", GROUP="video"
>
>
> jaunty:
> KERNEL=="dv1394[0-9]*", NAME="dv1394/%n", GROUP="video"
> KERNEL=="video1394[0-9]*", NAME="video1394/%n", GROUP="video"
>
> I suppose the rule:
> KERNEL=="raw1394", GROUP="disk"
>
> should be added as well.
>
We opted to remove this rule.

If you want it, you can always put it back in a file
in /etc/udev/rules.d instead

Scott
--
Scott James Remnant
<email address hidden>

This bug was fixed in the package udev - 141-2+git4a74214

---------------
udev (141-2+git4a74214) karmic; urgency=low

  * Update to GIT HEAD:
    - bugfixes. LP: #369817, #368109.
    - libudev allows you to subscribe to udev events, and filter those
      based on system, etc.
    - extras/cdrom_id/cdrom_id.c: Add a new key ID_CDROM_MEDIA=1 if there
      is a CD present. Also, skip media tests if CDROM_DRIVE_STATUS !=
      CDS_DISC_OK.
    - rules/rules.d/60-persistent-storage.rules: Only start vol_id if
      ID_CDROM_MEDIA is set. This should fix the auto-closing of the tray.
      (LP: #356631)

  * Remove /dev/MAKEDEV symlink on upgrade.
  * Remove /dev/kmem device node, this is disabled in our kernels and
    will be created anyway if the module is loaded from a kernel compiled
    with it enabled.

  * The vol_id binary and libvolume-id library are no longer built by
    this package. Software should use the blkid binary and libblkid
    library supplied by the util-linux source package instead.
  * Add Breaks on packages that were using vol_id with our blessing.

 -- Scott James Remnant <email address hidden> Thu, 07 May 2009 12:48:24 +0100

According to comment #6, the bug was fixed (udev - 141-2+git4a74214)

Three months before, I am running an Ubuntu 9.04 fully updated and still have a wrong version (udev - 141-1.2)

Is this update going to be released in Ubuntu 9.04?

Anyway, I have examined the diff files, an I can find the solution for 'dv1394' and 'video1394', but I am not able to see any changes related to the raw1394 device.

-KERNEL=="dv1394[0-9]*", NAME="dv1394/%n", GROUP="video"
-KERNEL=="video1394[0-9]*", NAME="video1394/%n", GROUP="video"
+KERNEL=="dv1394-[0-9]*", NAME="dv1394/%n", GROUP="video"
+KERNEL=="video1394-[0-9]*", NAME="video1394/%n", GROUP="video"

Ca I fix the /dev/raw1394 device in this file of rules (in order to capture miniDV video with Kino) or should I keep on using the old "solution", every time I go to capture video?

$ sudo chmod 666 /dev/raw1394

Thanks in advance and excuse my limited English knowledge.

See LP: #6290 (and LP: #421551) for a further discussion of the permission issues.