Bug 445100 - unable to run dvgrab as ordinary user
unable to run dvgrab as ordinary user
Status: CLOSED DUPLICATE of bug 441073
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-03 14:07 EDT by Mads Villadsen
Modified: 2013-03-05 22:55 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-18 16:20:43 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)

  None (edit)
Description Mads Villadsen 2008-05-03 14:07:50 EDT
Description of problem:
When running dvgrab as an ordinary user the following error appears:

[maxx@ice ~]$ dvgrab -autosplit -format raw -size 0 -timestamp foo-
Error: no camera exists

Running as root correctly starts the grabbing proces.

Version-Release number of selected component (if applicable):
kernel-2.6.25-14.fc9.i686
libavc1394-0.5.3-2.fc9.i386
libraw1394-1.3.0-6.fc9.i386
libdc1394-2.0.1-4.fc9.i386
dvgrab-3.1-2.fc9.i386


How reproducible:
Always

Steps to Reproduce:
1. Connect dv camera
2. Run dvgrab as ordinary user
3. See error
  
Actual results:
Error

Expected results:
Grabbing should start

Additional info:
The following appears in /var/log/messages when connecting camera:

May  3 19:59:41 localhost kernel: firewire_core: BM lock failed, making local
node (ffc0) root.
May  3 19:59:41 localhost kernel: firewire_core: phy config: card 0, new
root=ffc0, gap_count=5
May  3 19:59:42 localhost kernel: firewire_core: phy config: card 0, new
root=ffc1, gap_count=5
May  3 19:59:45 localhost kernel: firewire_core: created device fw1: GUID
0000f0000c480971, S400, 1 config ROM retries
Comment 1 Jarod Wilson 2008-05-04 14:42:26 EDT
Access permissions should be properly set when you do a graphical login (works
for me, anyhow). Is this an ssh login or console login, by chance? I suppose we
ought to have something that works there too, if it doesn't...
Comment 2 Mads Villadsen 2008-05-04 15:48:49 EDT
This is with a graphical login (GNOME if it makes a difference). After plugging
in the camera here is what I get:

[maxx@ice defs]$ ll /dev/fw*
crw-rw----  1 root root 248, 0 2008-05-04 08:00 /dev/fw0
crw-rw----+ 1 root root 248, 1 2008-05-04 21:45 /dev/fw1
Comment 3 Bug Zapper 2008-05-14 06:36:06 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Jarod Wilson 2008-05-15 18:10:18 EDT
Crap. I've got the same thing happening on my own F9 laptop now. I'll see what I
can figure out...
Comment 5 Piergiorgio Sartor 2008-06-03 05:25:24 EDT
(In reply to comment #4)
> Crap. I've got the same thing happening on my own F9 laptop now. I'll see what I
> can figure out...

Jarod, it seems to me that, on F9,
/etc/security/console.perms.d/50-default.perms is missing some entry for the
"fw" devices.
Maybe this is a "pam" issue...

pg
Comment 6 Jarod Wilson 2008-06-03 10:07:27 EDT
Nope, firewire device access control is no longer handled by console.perms, its
handled by hal, via /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi.
I'm clueless about these inner workings though, no idea why its not working,
since I clearly see the ieee1394-avc device type defined in there alongside the
ieee1394-iidc device type, which does work... I think I'm going to kick this bug
over to the hal component, I'm guessing the hal folks might have an idea off the
top of their heads what's wrong.
Comment 7 Jarod Wilson 2008-06-03 10:18:03 EDT
Ah, fun... So I think I see part of why dvgrab is falling down, while iidc is
working... dvgrab actually needs read/write perms on the fw* device node of the
controller the camera is hooked to, it would appear. Just chowning the device
node of the camera to my user still results in no camera found, but chowning the
device node of the controller the camera is hooked to gets things working. Not
quite sure how we handle this in hal though, since I'm not sure it knows (or is
even supposed to know) which device node is the controller the camera is hooked
to...
Comment 8 Piergiorgio Sartor 2008-06-04 03:33:38 EDT
(In reply to comment #7)
> Ah, fun... So I think I see part of why dvgrab is falling down, while iidc is
> working... dvgrab actually needs read/write perms on the fw* device node of the
> controller the camera is hooked to, it would appear. Just chowning the device

Now that you mention I remember I reached the same conclusion while playing
around with dvgrab & kino.
It could even be, not sure, that *only* the controller node need to be "rw" by
the user accessing the camera (to be confirmed).

Could it be a libraw1394 issue? Maybe it is not really correct what is done there...

pg
Comment 9 Chris MacGregor 2008-06-15 14:26:32 EDT
After chowning /dev/fw0 (the controller, I guess, as /dev/fw1 seems to be the
camera), I am able to run dvgrab as myself, but I do get these additional two
warnings:

Warning: Cannot set RR-scheduler
Warning: Cannot disable swapping

Is dvgrab only meant to be run as root?  How might one reasonably allow an
ordinary user process to make such adjustments?  (I haven't looked at the dvgrab
source to see what it's trying to do, but I can guess pretty well.)
Comment 10 Jarod Wilson 2008-07-02 12:25:42 EDT
(In reply to comment #9)
> After chowning /dev/fw0 (the controller, I guess, as /dev/fw1 seems to be the
> camera), I am able to run dvgrab as myself, but I do get these additional two
> warnings:
> 
> Warning: Cannot set RR-scheduler
> Warning: Cannot disable swapping
> 
> Is dvgrab only meant to be run as root?  How might one reasonably allow an
> ordinary user process to make such adjustments?  (I haven't looked at the dvgrab
> source to see what it's trying to do, but I can guess pretty well.)

I don't recall getting these messages when running as non-root myself, but I'd
have to double-check that. We're definitely meant to run as non-root though.
Comment 11 Piergiorgio Sartor 2008-12-03 10:36:57 EST
Any news on this topic?
The problem seems to affect also F10, if it is just a hal configuration problem, maybe it would be worth to try some fix.

Thanks,

pg
Comment 12 Jarod Wilson 2008-12-18 16:20:43 EST
Related closely to bug 441073. In fact, I'm going to close-dupe this one, since its not moved anywhere in 5 months, and Stefan has some useful suggestions in the other one.

*** This bug has been marked as a duplicate of bug 441073 ***

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