Bug 441073 - user firewire permissions and dvgrab
user firewire permissions and dvgrab
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: libraw1394 (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
: 191670 445100 475166 (view as bug list)
Depends On:
Blocks: F9Target
  Show dependency treegraph
 
Reported: 2008-04-05 17:13 EDT by Paul Jenner
Modified: 2013-03-05 22:45 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-21 16:32:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace output (8.01 KB, application/octet-stream)
2008-04-05 17:28 EDT, Paul Jenner
no flags Details
strace output on F9 (8.07 KB, application/octet-stream)
2008-06-29 08:53 EDT, Paul Jenner
no flags Details

  None (edit)
Description Paul Jenner 2008-04-05 17:13:44 EDT
Description of problem:
Permissions on firewire devices do not allow dvgrab to be run as non-root user.

There are a number of bug reports referring to this but no single clear bug that
I could find so raising new to capture just this.

Version-Release number of selected component (if applicable):
[psj@localhost ~]$ rpm -q dvgrab udev hal kernel
dvgrab-3.0-2.fc7
udev-116-3.fc7
hal-0.5.9-8.fc7
kernel-2.6.23.17-85.fc7

How reproducible:
Always.

Steps to Reproduce:
1. Connect firewire camera
2. Run "dvgrab" as non-root user logged in to console (e.g. X)
  
Actual results:
[psj@localhost ~]$ dvgrab 
Error: no camera exists

Expected results:
[root@localhost home]# dvgrab 
Found AV/C device with GUID 0x0080880307303c63
Comment 1 Paul Jenner 2008-04-05 17:25:27 EDT
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).
Comment 2 Paul Jenner 2008-04-05 17:28:41 EDT
Created attachment 301392 [details]
strace output
Comment 3 Paul Jenner 2008-04-05 17:30:44 EDT
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).
Comment 4 Paul Jenner 2008-04-05 17:33:40 EDT
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.
Comment 5 Paul Jenner 2008-04-05 17:40:23 EDT
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)
Comment 6 Jarod Wilson 2008-04-05 17:43:23 EDT
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...
Comment 7 Bug Zapper 2008-05-14 11:25:13 EDT
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
Comment 8 Paul Jenner 2008-06-28 10:31:09 EDT
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
Comment 9 Paul Jenner 2008-06-29 08:53:08 EDT
Created attachment 310537 [details]
strace output on F9
Comment 10 Paul Jenner 2008-06-29 08:58:18 EDT
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.
Comment 11 Stefan Richter 2008-08-14 10:52:52 EDT
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).
Comment 12 Stefan Richter 2008-08-14 11:45:33 EDT
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)
Comment 13 Stefan Richter 2008-08-20 12:39:18 EDT
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.
Comment 14 Stefan Richter 2008-08-20 15:53:02 EDT
I posted a review of firewire in upstream udev to linux-hotplug and linux1394-devel:  http://marc.info/?l=linux-hotplug&m=121926128127732
Comment 15 Stefan Richter 2008-08-20 16:59:46 EDT
Current Fedora FireWire udev rules are a result of bug 240770.
Comment 16 W. Michael Petullo 2008-11-29 12:39:40 EST
*** Bug 191670 has been marked as a duplicate of this bug. ***
Comment 17 Stefan Richter 2008-11-29 13:21:38 EST
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.
Comment 18 Jarod Wilson 2008-12-18 16:20:43 EST
*** Bug 445100 has been marked as a duplicate of this bug. ***
Comment 19 Paul Jenner 2008-12-30 12:30:56 EST
Confirmed in Fedora 10.
Comment 20 Paul Jenner 2008-12-30 12:41:04 EST
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
Comment 21 Paul Jenner 2008-12-30 12:43:14 EST
Changed component to libraw1394 - confirmed above that this is a library issue and not dvgrab which just uses the library.
Comment 22 Stefan Richter 2009-01-02 07:09:26 EST
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.
Comment 23 Stefan Richter 2009-01-10 13:35:07 EST
proposed patch:
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/12941
Comment 24 Piergiorgio Sartor 2009-01-14 14:23:21 EST
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
Comment 25 Fedora Update System 2009-01-14 17:08:44 EST
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
Comment 26 Fedora Update System 2009-01-15 10:33:09 EST
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
Comment 27 Fedora Update System 2009-01-16 18:40:39 EST
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
Comment 28 Fedora Update System 2009-01-16 18:41:22 EST
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
Comment 29 Paul Jenner 2009-01-18 14:59:08 EST
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
Comment 30 Fedora Update System 2009-01-21 16:32:19 EST
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.
Comment 31 Kevin Kofler 2009-02-24 22:59:14 EST
*** Bug 475166 has been marked as a duplicate of this bug. ***
Comment 32 Diederik van Lierop 2009-12-25 14:15:36 EST
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::---
Comment 33 Stefan Richter 2009-12-25 14:42:42 EST
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?
Comment 34 Diederik van Lierop 2009-12-25 15:32:41 EST
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!
Comment 35 Stefan Richter 2009-12-25 15:46:37 EST
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.)

Note You need to log in before you can comment on or make changes to this bug.