Bugzilla – Bug 104426
Access to pilot device or any serial/usb devices requires root privileges
Last modified: 2005-08-24 09:00:40 UTC
When I plug-in a pilot device and try to sync with evolution, it doesn't even get configured. The reason being the lack of write-permission on the created /dev/tty* device nodes. The user has to either add himself to the uucp group or use resmgr to get an access to that device. The same applies to digital-camera's as well. Access to these devices shouldn't need root privileges.
access to serial devices will not be granted by default. There could be a modem connected which would open a hole for dialers. if hal is able to detect that the connected device is not a modem but a harmless device we can add it by default to some ressource class. Please attach output from lshal with the device connected. camera access is already fixed.
Created attachment 46023 [details] output from lshal after pressing HotSync button on a USB Palm m130 The /dev/ttyUSB0 exists only after pressing HotSync button, not after pluging the Palm into the USB. After HotSync /dev/ttyUSB0 dissapears from /dev again.
The device actually provides two serial ports. ttyUSB1 has additional properties that indicate it's a pda. ttyUSB0 looks like a regular serial port. So with the current information it's not possible to have a generic match rule that could distinguish pda and modem.
Hmm, those pda properties come from /usr/share/hal/fdi/information/10freedesktop/10-usb-pda.fdi They explicitely match for the second serial port and don't add the properties to the first.
I'll add a pda class to resmgr and include it in class desktop. Then all that's needed to support pda access is proper detection from hal, reassigning to hal maintainer.
Yes, on pressing HotSync button, two ports will be created, and the second port will have the properties of a pda.
Ludwig: is it enough to set pda.platform = 'palm' for both ports and you match in hal-resmgr for this key, or is it also need to add pda.platform = 'palm' (or something else) to the usb-device?
reassign to lnussel: as disccussed, check if there are any security problems. If not I change the fdi file for the second serial port, but if there are any objection we must use maybe suseplugger for this.
Seems there are too many different devices to be able to determine the correct serial port. Let's hope the visor driver only matches actually only pda and not some mobile+pda combo devices. I'll add all devices that have pda.platform set into the resmgr class pda now. Danny will fix the hal fdi file for pdas so both serial ports get that property.
fixed in the HAL fdi file and pushed upstream. Reassign back to ludwig.
Veerapuram: can you tell me which of the both serial ports is the really hotsync interface? ttyUSB0 or ttyUSB1. I would like to add this special case correct to the HAL fdi file.
In my case pilot-xfer was able to communicate with ttyUSB0, not with ttyUSB1. USB Palm m130. I'll wonder if other models are using different tty, but I'm not sure. Veerapuram: Is it same in your case?
@Ladislav: can you please attach a output of lshal to the bug?
Already attached in comment #2.
Created attachment 46872 [details] udev rules
Comment on attachment 46872 [details] udev rules Ah!! sorry was on leave. @Ladislav, @Danny: In my case, it is the second port (i.e,) ttyUSB1. I have Handspring Visor and Tungsten T5. Also, I have written a udev rules file for creating a link when such devices are attached. Don't know whether that would help you in anyway, however attaching it here. Also, I modified the /etc/group file and added the corresponding user to the uucp group for write access. Will attach lshal output shortly.
@Ladislav: overlooked the attachment ;) @Veerapuram: please attach the output of lshal for each of the both devices. Is it ttyUSB1 in both cases?
Created attachment 46878 [details] lshal output after pressing hotsync button in Tungsten T5 Attaching the log of lshal command after during hotsync operation with Tungsten T5 palm device.
Created attachment 46882 [details] lshal output after pressing hotsync button in Handspring Visor (USB cradle) Attaching the output of lshal during the hotsync operation with Handspring Visor device (USB cradle).
@Danny: Yes, it is ttyUSB1 (or the second port, in general) for the devices that I have here.
a new hal-resmgr which adds pdas to resmgr is checked in
@Veerapuram: Looks like the visor kernel module isn't loaded for the Tungsten T5 and the Visor. Or is it? If not: is there a special reason? The devices should be handled by this module (vendorID and product ID match for this). Can you please load the module and attach a new version for lshal?
@Veerapuram: is the output of lshal from a SUSE 9.3 ? Looks like a machine with a old kernel and like the output of a hal version<=0.4.x
@Danny: <for #22>: The visor module was loaded, however, the device wasn't syncing because of disabling those udev rules. Attaching the new logs after modifying the /etc/group to let the user have proper rights on the usb port. for #23: Yes, I am using SuSE 9.3 :)
Created attachment 47305 [details] After adding the user to the uucp group
Created attachment 47306 [details] After adding the user to the uucp group
o.k. I added the devices for 10.0 to HAL to detect them as pda. Thanks.
No probs. If you want logs generated in a 10.0, can get you that as well. :)
You could me send them from the upcommit Beta 4 next week to verify if the changes work (send them pleas directly).
Sure, the moment I get Beta 4 here, will mail you the logs. Thanks.