Uses /dev/raw1394 by default rather than /dev/dv1394?

Bug #35693 reported by Duncan Lithgow
6
Affects Status Importance Assigned to Milestone
kino (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Kino cannot capture dv from ieee1394 as a normal user, it only works if kino is running as root.

strangely the permission are:
-rw-rw----
owner: root
group: disk

... and it makes no difference if the user is a member of the disk group

Revision history for this message
Dennis Kaarsemaker (dennis) wrote :

Scott, is this a udev bug or a case of application-needs-to-provide-udev-rule?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Neither.

/dev/raw1394 should only be writable by root.

Any attempt to change this will be considered a critical security bug as it provides a method for any user to execute arbitrary code on the system through access to any firewire device.

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote :

That's cool, but what now? We don't want people running Kino as root, which is what I have to do at the moment...

(I don't know if it's relevant but someone thought dv1394 might be a way around this?)

Duncan
https://wiki.ubuntu.com/UserDocumentation/ieee1394

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

dv1394 is owned by the "video" group, it's certainly the device that things like Kino *should* be using as it doesn't provide the kind of access to the devices that allows one to root a box.

From talking with Jody (kernel IEEE1394 subsytem maintainer) I understand that it doesn't provide access to all of the camera features though.

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote :

Kino does allow the choice between raw1394 and dv1394.

OK, so it's not a perfect solution and there is no /dev/dv1394 as far as I can tell... so I get no joy from dv1394

Running as root I get
>> Starting Capture
>>> Using dv1394 capture
dv1394 open: No such file or directory

Running as user I get the same after a bunch of other errors about "The IEEE subsystem is not responding"

What's our next move?

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote :

Someone on a SUSE list got it working with this:

 mknod -m 666 /dev/dv1394 c 171 34

I understand that this makes a node for dv1394 with looser permissions, but I don't understand the whole thing. Is this useful, I'm not going to try, becasue I don't understand it.

Duncan

Revision history for this message
Dan Dennedy (dan-dennedy) wrote :

Instead of using the more generic "disk" group, create a dedicated "raw1394" group and add users that want to use Kino, Cinelerra, Coriander, or other Firewire apps to this new group.

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote :

I have created a group: 'raw1394' and made user 'duncan' a member. Then I changed the group for /dev/raw1394 to 'raw1394'.

That makes no difference, which is no supprise because as I said in the original report, user 'duncan' being a member of group 'disk' made no difference either.

On a positive note, /dev/dv1394-0 has just turned up for some reason, so now user 'duncan' without being a member of group 'video' (which doesn't exist in my dapper install anyway). Also odd is that the setting in kino to use dv1394 instead raw1394 seems to be forgotten each time I close kino. As noted dv1394-0 does not support all camera features, in my case it supports exactly zero camera features, complaining that 'No AV/C compliant cam connected or not switched on?'

So, user 'duncan' can capture while the camera is manually set to play.

But, what is the solution to users being able to access the AV controls? At the moment it is still only possible as root.

Revision history for this message
Dan Dennedy (dan-dennedy) wrote :

It is not correct that you must be a root user. I do not know why it does not work for you. I have Ubuntu Breezy installed at work, but I have no Firewire in that machine, but I believe it should work. On my main workstation, I do not use Ubuntu, and I have no problem. Furthermore, since I have been developing Kino for over 5 years, I have never been in a situation requiring root regardless of distro and version used.

The change I suggested is meant to be considered as a new Ubuntu default that will work for users whose environments are not screwed up--as apparantly yours is.

Also, FYI, support for dv1394 in Kino is going to go away soon, and it require raw1394 for all Firewire I/O.

Revision history for this message
Dan Dennedy (dan-dennedy) wrote :

As a test to debug your situation, try this... make sure group raw1394 has read/write access to /dev/raw1394, create a new user, add new user to raw1394 group (and other applicable groups like audio). Then login as new user and try using Kino. Since the dv1394 selection is not saving between Kino sessions, I suspect that your Kino config file is not writable, and maybe even not readable by your normal user account since it was created under root/sudo.

Revision history for this message
Matt Zimmerman (mdz) wrote :

If kino is using raw1394 rather than dv1394 by default, that is kino's bug

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote :

Matt, please read the previous posts more carefully. You are incorrect. dv1394 is being phased out by the lib1394 developers. I don't pretend to know what the solution is, but it's not a kino problem as far as I can see. It is actually quite easy to make kino work with dv1394, but dv1394 doesn't support the AV controls for starting stopping, rewinding the camera etc.

Revision history for this message
Alan Pater (alan-pater) wrote :

When I add the user to the 'disk' group & restart the Gnome session, it works. This was the case both with Breezy and now with Dapper.

I never did not run Kino as root first, only as a normal user.

But how does one configure Kino to use dv1394 instead?

Revision history for this message
Martin Pitt (pitti) wrote :

Closing as duplicate of bug #6290.

Changed in kino:
status: Unconfirmed → Rejected
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.