success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
I found easy way to ugen problem: in /etc/devfs.rules I added [local_ruleset=10] add path 'ugen*' mode 664 then in /etc/rc.conf devfs_system_ruleset=local_ruleset And this is it. Now user can acces camera (PowerShots50) with gtkam. The resolution was given by (http://lists.freebsd.org/pipermail/freebsd-current/2003-September/009706.html) Jeff Walters*. *Based on man devfs it is impossible to resolve this issue. * * ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
Hi, have severe problems accessing usb devices as non-root user. In this case a Canon Powershot G5 camera. I want to download pics from my digicam using digikam application as user andreas. The devices that are being used by digikam: [EMAIL PROTECTED] ~ lsof | grep digikam | grep /dev digikam 1755root0u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root1u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root2u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root 15u VCHR 114,16 0t0 128 /dev/ugen1 digikam 1755root 16r VCHR 114,17 0t7817 131 /dev/ugen1.1 digikam 1755root 17r VCHR 114,190t16 133 /dev/ugen1.3 Running digikam with SUID root bit turned on doesn't work. [EMAIL PROTECTED] ~ digikam The KDE libraries are not designed to run with suid privileges. Changing the permissions on /dev/ugen1* doesn't work either since - even _if_ the devices are present after turning camera on and - even _if_ permissions of /dev/ugen1 /dev/ugen1.1 ... 1.3 are being changed successfully to 666 the devices seems to be on the 1st access dynamically recreated, since the permissions suddenly are *re-set* to root 644 automagically after the 1st access of the digikam application as user. To sum up: as normal user I'm unable to connect to the USB camera. Is there a more generic approach to be able to use USB devices as non-root user, that I overlooked up to now ? Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
On Mon, Oct 20, 2003 at 12:19:46PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm wri tes: Hi, have severe problems accessing usb devices as non-root user. In this case a Canon Powershot G5 camera. I want to download pics from my digicam using digikam application as user andreas. Use the devfs(8) command to request changes the owner or modes to suit your needs. This works a bit like firewall rules and when the device is created the modes/owner is set. Good idea. But no success and inexpected results. Well now I use both /etc/devfs.conf and devfs rule add in /etc/rc.local. It was 1st unclear to me after reading the devfs(8) manpage, that the devfs rule add - command 1st needs a command like devfs ruleset 100 So now I have 1) /etc/devfs.conf with: permugen1 0666 permugen1.1 0666 permugen1.2 0666 permugen1.3 0666 and 2) devfs rule show 100 path ugen mode 666 I halted system, turned camera off and on Booted FreeBSD. 1. Step, check permissions without having started any camersa application ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-rw-rw- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-rw-rw- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-rw-rw- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 You see the camera is on, therefore the ugen1 devices have been created. Good so far. A bit strange is, that ugen0 (USB printer) still has mode 644, this is the printer... I would expect, that the devfs rule 100 would have been applied by the system and it should be active for this device as well ! Note: And later we see, that even the permission of the ugen1 interface change again to 644 after the 1st access or whatever ! Well lets repeat, the machine is freshly restarted, camera was on and ugen1 devices have 0666. 2. step: start digikam as user [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-rw-rw- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-rw-rw- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-rw-rw- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 The startup itself is harmless nothing happens and no access to camera. The digikam application has a config files and presents the camera found in the last session (from config file). 3. step, try to access camera by klick on the Canon PowerShot G5 line in digikam failed to initialize the camera [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. Note: I think the lpd daemon accesses the printer on startup. Therefore the ugen0 device already had the new permission 644 which I observed in the previous step ! Any idea how to resolve this ? And BTW, shouldn't the devfs(8) manpage have a reference to devfs.conf ? I understand, that /etc/devfs.conf is only used by the /etc/rc.d/devfs startup script, to setup permissions via chmod commands and such so no real relationship to the devfs command. But I'd find it useful to have a reference to it. Or ... something like a devfs.conf(5) manpage is missing and a SEE ALSO devfs.conf(5) in devfs(8) is missing, what would probably be better ... Or what do you think ? -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
In message [EMAIL PROTECTED], Andreas Klemm writ es: 1) /etc/devfs.conf with: permugen1 0666 permugen1.1 0666 permugen1.2 0666 permugen1.3 0666 I would probably just use a wildcard: permugen* 0666 1st needs a command like devfs ruleset 100 This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. 3. step, try to access camera by klick on the Canon PowerShot G5 line in digikam failed to initialize the camera [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. And BTW, shouldn't the devfs(8) manpage have a reference to devfs.conf ? I understand, that /etc/devfs.conf is only used by the /etc/rc.d/devfs startup script, to setup permissions via chmod commands and such so no real relationship to the devfs command. Yes, probably a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
Poul-Henning, many thanks for you kind guidance to the wonderful world of devfs (which I never had to tweak in the past) ;-) On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: I would probably just use a wildcard: permugen* 0666 The wildcard feature is really fine ! Thanks for pointing me into that direction. This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. Good hint ! Thanks ! Well and now things work like expected. I put these devfs commands now into /etc/rc.local. But since /etc/rc.local officially has gone, I think this is not the best place ... After a longer examination of /etc/devfs, /etc/rc.subr /etc/defaults/devfs.rules and /etc/defaults/rc.conf I got the clue, that I can put the statements into /etc/devfs.rules. Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
In message [EMAIL PROTECTED], Andreas Klemm writ es: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) I personally end up less(1)'ing /etc/rc.d/* every time I want to do something... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
On Mon, Oct 20, 2003 at 02:40:00PM +0200, Poul-Henning Kamp wrote: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) That's not the right attitude for something that is 100% your baby. You've added a completely new subsystem to FreeBSD, one that people have no choice but to deal with when they move from 4.x to 5.x since you made devfs mandatory. It is YOUR responsibility to document it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm writ es: [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. An USB device can be switched between several alternative configurations. If such a change is requested (USB_SET_CONFIG) the devicenode for everything but the control channel is recreated. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
In message [EMAIL PROTECTED], Bernd Walter writes: On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm writ es: [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. An USB device can be switched between several alternative configurations. If such a change is requested (USB_SET_CONFIG) the devicenode for everything but the control channel is recreated. But the devfs rules should still set the mode when it is recreated... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
