Comment 4 for bug 16811

I will spare all the full story on the evolution of Linux 1394 :-), and instead, respond to
the key issue. Technically, it makes sense to load raw1394 and create /dev/raw1394 simply by having an
IEEE 1394 adapter in the system, although that might not seem interesting to most users :-). For example,
one can make the computer appear to be a DV or MPEG-2 VTR, so when a suitable device connects it may
control it and send/receive streams.

raw1394 is essentially a generic userspace interface into the kernel modules and provides access to any
and all devices and adapter through one device node. While this architecture makes it convenient for users
(less to configure, administer, and troubleshoot), it is also very coarse when it comes to security.
Unfortunately, I believe security has been an afterthought to Linux 1394 developers :-(. I will raise this
issue of coarseness to our team. Many devices are multi-protocol, which makes the situation rather
complicated. For example, a DV, HDV, or DTV device is identified via IEEE 1212 (CSR), controlled via AV/C,
and streams media according to IEC 61883.

In the meantime, due to this coarseness, I can only recommend that a distinct group named ieee1394 and
giving that group rw permission. BTW, it does not make sense to use a read only permission because this
special device node acts as a message queue between user and kernel space, and a read only permission will
render it useless.