Comment 13 for bug 152392

For the record, the simple fact is that the kernel firewire subsystem is entirely inadequate for your needs.

In past bugs, people have compared the expected functionality with the USB subsystem, but now compare the implementation.

For USB, we have, for each single device, a multitude of sysfs kobjects. There is a kobject for each hub on the wire, and under that a kobject for each port the hub has, and under that a kobject for each connected device (with a variety of interesting properties) and under that a kobject for each interface and endpoint that device has.

This gives us a great deal of flexibility to customise and limit the access to USB devices. At the very least, we can apply permissions on a device by device basis (ie. one user can access the iPod and another can access the camera); at the extreme case we can customise permissions on the actual interfaces.

Now look at Firewire.

You have a single kobject for the entire firewire host, with sometimes a kobject for the device directly connected to that host. No thought for hubs or multiple devices is given at all.

There are specialist subsystems that provide limited access to certain devices (dv1394, ieee1394, video1394, etc.) but they do not seem to have the functionality the applications require.

Instead applications use a "raw1394" device that provides complete and unfettered access to all 1394 devices on all hosts. It would be equivalent to having a "/dev/usb" that you could directly use to talk to any USB device.

To make matters worse, the IEEE1394 specification permits connected devices to execute code on the host system as a super-user. It is a relatively simple matter to construct a device that you can write arbitrary code to, and requests that it is executed. Opening /dev/raw1394 to ordinary users gives root access.

The ideal solution is for the kernel's firewire subsystem to have a complete, ground-up overhaul and be written much more along the lines of the USB subsystem.

Failing that, an interim solution would be if we could at least have some information from the kernel about _WHAT_ is connected on the firewire port when they are connected and disconnected, we don't even get that right now!

If we had insert notification, with vendor and device ids inside the uevent, we could at least enable access on a "per known device" basis -- I'd still be nervous about raw1394 though, since anyone can fake a device id pair.