Comment 8 for bug 20567

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