/dev/raw1394 permission not video group read/writtable

(In reply to comment #0)
> /dev/raw1394 is not read/writtable by the video group, and thus stops
> gnomemeeting, coriander and other such apps from using firewire based DV cams
> and webcams.
>
> I am not sure if this was expressely wanted, and people should use the
> /dev/video1394, altough people keep telling me that the raw device is better to
> access, and gnomemeeting and coriander default to the raw device.
>
> Friendly,
>
> Sven Luther

Hi.

raw1394 was the first generation of the firewire multimedia support in linux.
Then they added a number of modules (e.g. video1394, dv1394) to do some of the
parsing and buffering in-kernel. Now the linux1394 people seem to be back to
using the raw1394 device + helper libraries, but without extra kernel modules
and devices. They made a new library, libiec61883, that uses the raw1394_iso api
of libraw1394. And hence the raw1394 device.

(This is my impression of the development process -- not entirely sure of the
history.)

So the circle has come around. It seems they want you to use the raw1394 device,
even if you have a hard drive connected.

Near-term suggestion: Ubuntu should (probably) add a debconf option, either for
the owner of the device or its permissions. One would leave it 660 for disk, the
other would either be 666/disk or 660/video. Ubuntu should default to leaving
the device accessible, betting on firewire being used more for DV cameras than
for hard drives.

Longer-term solution: talk to upstream folks, see if maybe we can get a new
device added, iso1394, that would just be for isochronous operations (mainly
multimedia), get it owned by video.

One more data point -- any project using libraw1394 for capture will need the
raw1394 device available. I need it for GStreamer and Flumotion.

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.

We've seen this one before.

The problem with making the raw firewire device writable by any group is that it
gives full permission to all members of that group to access any firewire device
however they see fit.

Firewire devices aren't just video devices, they can include things like storage
devices as well as other things too.

It would be like giving the world raw access to the USB bus simply because one
particular brand of webcam software didn't want to use /dev/video0

This bug has been marked as a duplicate of bug 20567.