Bug 441073

Firewire devices and permissions before camera plugged in:

[psj@localhost ~]$ ls -ld /dev/fw*
crw-rw---- 1 root root 251, 0 2008-04-05 22:18 /dev/fw0

Firewire devices and permissions after camera plugged in:

[psj@localhost ~]$ ls -ld /dev/fw*
crw-rw----  1 root root 251, 0 2008-04-05 22:18 /dev/fw0
crw-rw----+ 1 root root 251, 1 2008-04-05 22:22 /dev/fw1

[psj@localhost ~]$ getfacl /dev/fw0
getfacl: Removing leading '/' from absolute path names
# file: dev/fw0
# owner: root
# group: root
user::rw-
group::rw-
other::---

[psj@localhost ~]$ getfacl /dev/fw1
getfacl: Removing leading '/' from absolute path names
# file: dev/fw1
# owner: root
# group: root
user::rw-
user:psj:rw-
group::rw-
mask::rw-
other::---

Where psj is the non-root user logged in to the console (via GNOME session).

Created attachment 301392 [details]
strace output

Captured strace output from dvgrab attached ends with:

inotify_init()                          = 6
inotify_add_watch(6, "/dev", IN_CREATE) = 1
epoll_ctl(3, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=190305064, u64=4485272360}}) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN, {u32=190305068, u64=4485272364}}) = 0
open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=4740, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
getdents(7, /* 217 entries */, 4096)    = 4096
open("/dev/fw1", O_RDWR)                = 8
ioctl(8, 0xc0242300, 0xbfba4048)        = 0
close(8)                                = 0
open("/dev/fw0", O_RDWR)                = -1 EACCES (Permission denied)
getdents(7, /* 20 entries */, 4096)     = 368
getdents(7, /* 0 entries */, 4096)      = 0
close(7)                                = 0
close(6)                                = 0
close(4)                                = 0
close(5)                                = 0
close(3)                                = 0
futex(0xbfcae8, FUTEX_WAKE, 2147483647) = 0
write(2, "Error: no camera exists\n", 24) = 24
write(2, "\n", 1)                       = 1
exit_group(0)                           = ?

Note trying to open /dev/fw0 for read which the user does not have permissions
to (after successfully opening /dev/fw1 for read which they do).

Working around this by setting user permissions on /dev/fw0 manually to match
/dev/fw1:

[root@localhost ~]# setfacl -m u:psj:rw /dev/fw0

[psj@localhost ~]$ ls -ld /dev/fw0
crw-rw----+ 1 root root 251, 0 2008-04-05 22:18 /dev/fw0
[psj@localhost ~]$ getfacl /dev/fw0
getfacl: Removing leading '/' from absolute path names
# file: dev/fw0
# owner: root
# group: root
user::rw-
user:psj:rw-
group::rw-
mask::rw-
other::---

[psj@localhost ~]$ dvgrab 
Found AV/C device with GUID 0x0080880307303c63
Warning: Cannot set RR-scheduler
Warning: Cannot disable swapping
Capture Started

Non-root user is now able to use dvgrab to capture from firewire camera
successfully.

Bugs that refer to non-root firewire permission problems and dvgrab but do not
appear to be as clear: #191670 #243081 (comment 1) #344851 (comment 27)

This is a hal or udev or consolekit or policykit or something issue, that I
believe is fixed in F8... But obviously, I'm not sure exactly which component it
is... krh may well know...

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Confirmed exactly the same behaviour in F9 - same device node permissions before
and after the camera is plugged in, same failure as non-root user, same
workaround of setting non-root user acl on /dev/fw0 is successful.

[psj@localhost ~]$ rpm -q dvgrab udev hal kernel
dvgrab-3.1-3.fc9.i386
udev-120-5.20080421git.fc9.i386
hal-0.5.11-2.fc9.i386
kernel-2.6.25-14.fc9.i686
kernel-2.6.25.6-55.fc9.i686

Created attachment 310537 [details]
strace output on F9

Captured strace output again ends with:

inotify_init()                          = 6
inotify_add_watch(6, "/dev", IN_CREATE) = 1
epoll_ctl(3, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=185799480, u64=185799480}}) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN, {u32=185799484, u64=185799484}}) = 0
open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=4660, ...}) = 0
fcntl64(7, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents(7, /* 214 entries */, 4096)    = 4096
open("/dev/fw1", O_RDWR)                = 8
ioctl(8, 0xc0242300, 0xbff96eb8)        = 0
close(8)                                = 0
open("/dev/fw0", O_RDWR)                = -1 EACCES (Permission denied)
getdents(7, /* 19 entries */, 4096)     = 344
getdents(7, /* 0 entries */, 4096)      = 0
close(7)                                = 0
close(6)                                = 0
close(4)                                = 0
close(5)                                = 0
close(3)                                = 0
futex(0x21d7728, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "Error: no camera exists\n", 24) = 24
write(2, "\n", 1)                       = 1
exit_group(0)                           = ?

Showing the problem with user being unable to open /dev/fw0 due to permissions.

Paul Jenner wrote:
> Working around this by setting user permissions on /dev/fw0 manually to
> match /dev/fw1

Well, then that's possibly a bug in dvgrab or libraw1394.  dvgrab should keep running, leaving /dev/fw0 alone and accessing the camera through /dev/fw1.  I haven't tested this myself yet; I don't use ACLs (or Fedora even).

BTW, coriander (a capture program for industrial cameras, using libdc1394) is working just fine if it only has access to the camera's file but not to the controller's file.

gscanbus:  fails
firecontrol:  fails
dvgrab:  caught in a loop of nanosleep  (dvgrab 3.1 on Gentoo)

If access to the local node is granted (in addition to access to an AV/C capable node), then
  - dvgrab,
  - firecontrol,
  - gscanbus,
  - kino
work fine.  Of course firecontrol and gscanbus won't be able to communicate with nodes whose permissions are still the default strict ones, but this may be considered a feature rather than a bug.

A problem is that the firewire-core sysfs interface does not export any hint whatsoever whether a node is a local node or not.  An udev rule like
SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", [...]
will catch local nodes, but also remote nodes if they ran Linux/Juju.

Of course security of remote Linux nodes is the business of the remote node's stack, not the local kernel's or userland's task.  Anyway; the glass-half-full message here is that we _can_ keep access to SBP-2 devices disabled (if we don't count hypothetical Linux/Juju nodes running SBP-2 target software) and still get existing libraw1394 clients going --- we just need to open up the local node for user access.

I posted a review of firewire in upstream udev to linux-hotplug and linux1394-devel:  http://marc.info/?l=linux-hotplug&m=121926128127732

Current Fedora FireWire udev rules are a result of bug 240770.

*** Bug 191670 has been marked as a duplicate of this bug. ***

Somebody should investigate whether libraw1394 can be modified so that multimedia applications like dvgrab and kino don't need access to the local node's character device file.

In the meantime, the Fedora policykit or consolekit package should be modified to grant user access to the local node, as per comment 13 and comment 14.

*** Bug 445100 has been marked as a duplicate of this bug. ***

Confirmed in Fedora 10.

Details on the upstream IEEE 1394/ FireWire drivers wiki dated 29/12/2008 here:

http://ieee1394.wiki.kernel.org/index.php/Juju_Migration

See "Permissions and ownership for /dev/fw*" section

Changed component to libraw1394 - confirmed above that this is a library issue and not dvgrab which just uses the library.

Re comment 17:
See http://marc.info/?l=linux1394-devel&m=123089504900333  ---  David Moore pointed out that libraw1394 accesses the local node(s) in order to determine how many controllers are present.  Furthermore, the local node is used as the default node for several operations which many libraw1394 clients need, even though a different node (e.g. camcorder) could be used for their purposes.  We should be able to fix most of these issues by modifications to libraw1394.  Remaining issues require kernel driver changes, but these don't affect dvgrab, kino, and similar high-level applications.

proposed patch:
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/12941

I just noticed that F11 (Rawhide) got a new libraw1394 with, if I understood correctly, the proposed patch.

Jarod, any chance to get a similar update to F10?

Thanks,

pg

libraw1394-2.0.0-6.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libraw1394-2.0.0-6.fc10

libraw1394-2.0.1-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libraw1394-2.0.1-1.fc10

libraw1394-2.0.1-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libraw1394'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0574

libraw1394-2.0.0-6.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libraw1394'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0590

libraw1394-2.0.0-6.fc10 works for me.

I am able to use dvgrab to capture as non-root user with default permissions on the firewire devices:

[psj@localhost ~]$ rpm -q libraw1394
libraw1394-2.0.0-6.fc10.i386
[psj@localhost ~]$ ls -ld /dev/fw*
crw-rw----  1 root root 248, 0 2009-01-18 08:43 /dev/fw0
crw-rw----+ 1 root root 248, 1 2009-01-18 19:46 /dev/fw1
[psj@localhost ~]$ getfacl /dev/fw*
getfacl: Removing leading '/' from absolute path names
# file: dev/fw0
# owner: root
# group: root
user::rw-
group::rw-
other::---

# file: dev/fw1
# owner: root
# group: root
user::rw-
user:psj:rw-
group::rw-
mask::rw-
other::---

[psj@localhost ~]$ id
uid=500(psj) gid=500(psj) groups=500(psj),503(music),504(photos),505(videos),506(shareddocs) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[psj@localhost ~]$ dvgrab 
Found AV/C device with GUID 0x0080880307303c63
Warning: Cannot set RR-scheduler
Warning: Cannot disable swapping
Capture Started
^C"dvgrab-002.dv":     6.73 MiB 49 frames timecode 00:01:18.23 date 2009.01.18 09:18:59
Capture Stopped

libraw1394-2.0.1-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

*** Bug 475166 has been marked as a duplicate of this bug. ***

Problem still exists in Fedora 12. 

I get the "no camera exists" message when running dvgrab as a regular user, but it runs just fine when I start dvgrab as root

[root@localhost Film]# dvgrab
Found AV/C device with GUID 0x0080458011831847
Capture Started
"dvgrab-001.dv":   999.89 MiB  7281 frames timecode 00:04:52.01 date 2009.04.12 10:48:26

Running kernel 2.6.31.6-145.fc12.x86_64 #1 SMP

# rpm -q libraw1394
libraw1394-2.0.4-1.fc12.x86_64

# ls -ld /dev/fw*
crw-rw----. 1 root root  249, 0 2009-12-25 17:24 /dev/fw0
crw-rw----. 1 root video 249, 1 2009-12-25 19:49 /dev/fw1

# getfacl /dev/fw*
getfacl: Removing leading '/' from absolute path names
# file: dev/fw0
# owner: root
# group: root
user::rw-
group::rw-
other::---

# file: dev/fw1
# owner: root
# group: video
user::rw-
group::rw-
other::---

Re comment 32:
libraw1394-2.0.4-1.fc12.x86_64 should be a version with all necessary fixes.
Does the command "id" show that your user account belongs to the "video" group?

When I do just "id" then it doesn't.

# id
uid=500(diedenrezi) gid=500(diedenrezi) groups=500(diedenrezi) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

However

# id diedenrezi
uid=500(diedenrezi) gid=500(diedenrezi) groups=500(diedenrezi),39(video),501(videos)

Just created and added myself to "videos", because I noticed that Paul was member of that group. I was however already a member of "video" before that, if I recall correctly... which I'm starting to doubt now because it still didn't work at this point, but a reboot fixed it! Sorry for that, I lost the habbit of rebooting after installation shortly after switching to Linux completely ;-).

Thanks anyway, my problem has been solved.

Merry Christmas!

A "su -" after the group assignment change and before dvgrab would have been sufficient (i.e. a re-login) instead of full reboot. :-)

I wonder though:
1. How could video group membership of the account get lost?
2. Is it intentional that Fedora's udev + policykit (?) based infrastructure no longer sets ACLs on /dev/fw* files but changes group ownership of these files now?
(Compare ownership and ACLs of /dev/fw1 in comment 29 and comment 32.)