wrong permissions on /dev/raw1394

This is a raw firewire device socket, we should be a little more discreet than
giving one particular group like video permission to write to it ... after all,
there are more than just video firewire devices.

It seems (divining from a brief google) that you actually want to use the
/dev/video1394* or /dev/dv1394* nodes -- if you configure the software to use
those instead does that work?

Currently raw1394 is in group "disk", which seems to suggest it's for directly
accessing firewire disks. dv1394* and video1394* are in group "video". Another
option might be to change the group of the raw socket to something like plugdev.

Well, no, that didn't work for me, sorry. I did a quick test in Kino, specifying
/dev/dv1394 or /dev/video1394 or /dev/video1394 or /dev/video1394/0 (sorry I'm a
little clumsy, wanted to test everything), and it did not seem to work any
better. I could not capture.

I'm noticing that video apps all want to use RAW 1394 as default, not video or
dv. They all want to use /dev/raw1394. And they all say that the module is not
loaded or doesn't have proper read/write permissions.

(I'm writing in the context of being the Linux1394 upstream maintainer)

raw1394 is a module that gives raw access to the entire firewire bus. This means
reading and writing, which includes receiving and sending ISO streams.

This means that through this device one can send any sort of packet to any
device on the bus. It's akin to giving someone access to raw packets on an
ethernet device.

Because of this, the device needs root.root ownership. I can't argue for
anything else, even if programs require use of it just for video capture. Now,
I've used lots of video capture programs, including kino and coriander. Used it
with my Fire-I device, and my JVC video camcorder. They all worked with
video1394 (Fire-I), dv1394(JVC) and raw1394(both). So if the program isn't
working with video1394 or dv1394, then you should really take that up with that
program author. It's supposed to work.

As I recall with coriander, if you switched between video1394 and raw1394, it
wasn't as simple as selecting a different device name, you had to tell it you
were using video1394 or raw1394, and then the device path.

Then this isn't a udev bug -- you should configure your software to use the
video or dv device, and if that doesn't allow you to do that, file a bug on the
software.

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

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

Ben's characterization of Linux 1394 interfaces and modules is spot on. However, the situation is not as simple as Ben describes (the app
supporting dv1394 and/or video1394). First of all, to reap full functionality of video applications, the app may need to communicate with
device to setup a connection on a unique isochronous channel or simply to tell it to start transmitting. raw1394 is the only thing that can
provide this currently. Secondly, dv1394 is being deprecated in favor of a new isochronous API in raw1394, and libraries and applications
are building atop this (libiec61883, dvgrab, mythtv, freebob). Therefore, granularity of access control policy remains a major problem for
Linux 1394. My recommendation, given the current situation, to distributions is to create a new group, ieee1394, and recommend to admins to
add only "trusted users" to the group. If the goal is to create a very user friendly desktop, automatically add the user created during
install to the ieee1394 group for a desktop install but not a server install.

I am not sure what the long term solution should be. Having a simple kernel module and kernel interface has definitely helped Linux 1394
development to flourish (libraw1394, libavc1394, libiec61883, and all the apps that are using them). Can we somehow use Linux Capabilities
(by extending the list, if needed)?