Bug 220857 - Unable to access iriver as user - workaround found, please verify
Unable to access iriver as user - workaround found, please verify
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libifp (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Aurelien Bompard
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-27 20:50 EST by Peter Meyer
Modified: 2008-05-06 13:15 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 13:15:02 EDT
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 Peter Meyer 2006-12-27 20:50:00 EST
Description of problem:
I am unable to access my iriver using libifp-1.0.0.2-4.fc6 in user mode.

I have found a work-around involving manipulation of the udev entry.  Can you
verify that this is a good solution and please incorporate it into the next
release of this tool.

Version-Release number of selected component (if applicable):
libifp-1.0.0.2-4.fc6

How reproducible:

Always
Connect iriver mp3 player and powerup.
run ifpline ls as user  

Steps to Reproduce:
1.Connect iriver mp3 player and powerup.
2.run ifpline ls as user  <- will return a message to indicate the unit is busy
3.run ifpline ls as root  <- ifpline will display contents of mp3 player
  
Actual results:
will return a message to indicate the unit is busy

Expected results:
as user:
ifpline will display contents of mp3 player
  
Additional info:
Here is the workaround I created:
> mv 10-libifp.rules 52-libifp.rules  (gets this file after the 50-udev.rules file
change the content of 52-libifp.rules to be the following:
#ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102",
SYSFS{idProduct}=="100[135789]", RUN+="/sbin/libifp-hotplug"
ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}=="4102",
SYSFS{idProduct}=="100[135789]", OWNER="root", GROUP="ifp", MODE="0760",
RUN+="/sbin/libifp-hotplug", OPTIONs="last rule"
ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102",
SYSFS{idProduct}=="101[01]", RUN+="/sbin/libifp-hotplug"


Note I only changed the first line as I have an IFP-700 series.  I would expect
that both lines would need to be modified.

> Add your userid to unix group ifp.


Thoughts?
Comment 1 Aurelien Bompard 2007-01-11 09:14:23 EST
Thanks for this excellent bug report. I've implemented your ideas, in a slightly
different way which should not require you to add yourself to a (new) ifp group.
Please try these rpms:
http://gauret.free.fr/fichiers/rpms/fedora/libifp-1.0.0.2-5.i386.rpm
http://gauret.free.fr/fichiers/rpms/fedora/libifp-devel-1.0.0.2-5.i386.rpm
http://gauret.free.fr/fichiers/rpms/fedora/libifp-1.0.0.2-5.src.rpm
and tell me if it works for you (I don't own an IRiver).

If it's ok, I'll publish them.
Comment 2 Peter Meyer 2007-01-11 22:44:17 EST
Hi Aurelien:

....close

I looked at your /etc/security/console.perms.d/60-libifp.perms
rules.

This iriver device seems to get its identity from
/etc/udev/rules.d/50-dev.rules:305 ACTION=="add", SUBSYSTEM=="usb_device", \
   PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i
$${K%%%%.*} $${K#*.}'", \
    NAME="%c", MODE="0644"

From what I can tell, this code seems to set permissions or attributes on
/proc/usb/{bus}/{device}

When I made the proposed changes, it was to override this rule and permit this
device to be owned by a particular group and apply group readwrite permissions.

Comments?

Peter 
Comment 3 Peter Meyer 2007-01-11 22:53:22 EST
Unfortunately your fix does not work.  I am trying to find the attribute file
that gets modified with the changed group id and permissions.

The only think I keep seeing are changes in /dev/.udev/db point a
class@udev_device it creates as well as an entry
/dev/usbdev{bus}.{device}_ep[08][10]

I can't see where it stores the permissions for a given device.... sorry.
Comment 4 Aurelien Bompard 2007-01-12 04:15:16 EST
My objective it to avoid requiring the user to add himself to a group, I think
we can do it since the libmtp package does it. Unfortunately I don't own an
IRiver so I depend on you for testing.
What is the name of the device file which is created when you plug in the IRiver ?
Can you try after logging out completely and logging back in (to make sure the
new console.perms file is taken into account) ?
Thanks
Comment 5 Peter Meyer 2007-03-03 21:28:41 EST
Hello Aurelien:

I loaded your fix and rebooted the machine.  ifpline had to be run as root to
access the device.

I added in 52-libifp.rules:
#ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102",
SYSFS{idProduct}=="100[135789]", RUN+="/sbin/libifp-hotplug"
ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}=="4102",
SYSFS{idProduct}=="100[135789]", OWNER="root", GROUP="ifp", MODE="0760",
RUN+="/sbin/libifp-hotplug", OPTIONS=="last rule"
ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102",
SYSFS{idProduct}=="101[01]", RUN+="/sbin/libifp-hotplug"

unplugged and replugged in the iriver and was able to get user mode (albeit as a
member of the 'ifp' group to work.

Thoughts?

Peter
Comment 6 Aurelien Bompard 2007-03-04 03:49:22 EST
I understand it could work by requirering the user to add himself to the 'ifp'
group, but I'd like to avoid that if possible. What is the name of the device
file created when you plug in the IRiver ? Could you attach a sample of
/var/log/messages when you plug it in ?
Thanks.
Comment 7 Peter Meyer 2007-03-04 08:16:50 EST
Hi Aurelien:

I agree that having to add yourself to a group is not the way I would prefer
this to work:  Here are the logs from /var/log/message


On connection:
---------------
Mar  4 08:13:22 gandalf kernel: usb 4-5: new high speed USB device using
ehci_hcd and address 8
Mar  4 08:13:22 gandalf kernel: usb 4-5: configuration #1 chosen from 1 choice

On Disconnect:
-------------
 Mar  4 08:14:35 gandalf kernel: usb 4-5: USB disconnect, address 8
Comment 8 Aurelien Bompard 2007-03-08 01:46:56 EST
Anything else ? Do you know which module gets loaded when you plug in the IFP
(lsmod) ? Which device is created when you plug it in (ls -lrt /dev | tail) ?
Comment 9 Jon Stanley 2008-01-05 20:26:08 EST
I just noticed that someone added themselves to the CC list of this bug.  Is the
bug occuring in a current release of Fedora?
Comment 10 Till Maas 2008-01-05 20:36:18 EST
(In reply to comment #9)
> I just noticed that someone added themselves to the CC list of this bug.  Is the
> bug occuring in a current release of Fedora?

I do not know, yet. I have an iriver, but it currently uses the usb mass storage
device. I plan to flash it and test it, when I am in the mood. I just cc'ed me,
to  make it more likely not to forget it.
Comment 11 Peter Meyer 2008-01-05 23:11:54 EST
Hi.  I haven't played with this problem in some time.  I have not flashed my
iRiver device, and also not tested this on the latest version of Fedora.

In my notes above, I got around this problem by adding my user to the group I
created with the USB addition.  

I've also noticed that Ubuntu uses a technique of using groups to define user
rights when users are set up on a Ubuntu system.  Currently this issue is not a
problem on Ubuntu. 

This may not align with Fedora's strategy of assigning device ownership to the
first logged in user.

I wish I could comment further on this.  

Thanks for keeping this issue alive

Peter
Comment 12 Bug Zapper 2008-04-04 01:22:53 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 13 Bug Zapper 2008-05-06 13:15:01 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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