When gpsd is run in the foreground it runs as root. When it runs as a daemon it drops permissions and assumes the user "nobody" and guesses the group by examining the default tty permissions (believed to be group "tty"). However, a typical serial to usb adaptor GPS (or serial port) is group "uucp" on gentoo, and hence gpsd can no longer access any devices. I believe the best fix is to create a gpsd user which belongs in group uucp, then to build gpsd to drop user privileges to this user. Patch attached Reproducible: Always Steps to Reproduce:
Created attachment 201789 [details, diff] patch to gpsd-2.39.ebuild
The gpsd package has nothing to do with device permissions; udev has applied the correct USB-serial device permissions for some time now: # ls -l /dev/ttyUSB0 crw-rw---- 1 root uucp 188, 0 Aug 22 10:54 /dev/ttyUSB0 The above is the Deluo USB gps device I use for testing, which uses the PL2303 USB-serial adapter. All the gpsd rules do is launch the gpsd-hotplug thing when the device is plugged in; the alternative init script and config file are installed when the package is built without usb support (and still work fine with a USB gps device). The init script and config have just been updated for another bug, so feel free to try it without usb support, otherwise make sure your device is enabled in the 99-gpsd-usb.rules file. Feel free to post more of your system info and maybe we can figure out why your device comes up that way, but again, device permissions and ownership are not controlled by the gpsd package (it should work just fine the way it is now).
Thankyou for your reply, but I'm actually completely unsure what you are talking about?? You appear to be just repeating what I already said? Yes the permissions on my ttyUSB device are root:uucp, just like yours. I'm not clear why you are repeating this? Just in case I am not being clear - if the gpsd daemon is running as user nobody, group tty, then how can it access the device which is user root, group uucp, others no access? My patch changes the gpsd daemon to run as user gpsd, group uucp
I guess I don't understand; are you saying it doesn't work for you the way it is now? It works fine here with the normal udev/hal/plugdev setup. It should only require root to start the init script if you install gpsd without USB support. Either way, it works fine as a normal user running any of the gps clients (xgps, gpsdrive, etc). The above user is a member of the uucp, plugdev, audio, and other standard gentoo groups. I'm not sure exactly why you're trying to fix something that doesn't appear to be broken...
OK, so you are saying that you have no permissions problem as the ebuild is supplied? This is odd. My setup is USE="ntp usb", then install gpsd-2.39. There is no startup script, so on hotplugging my device the hotplug script starts the daemon as "gpsd -F /var/run/gpsd.sock". When gpsd runs as a daemon it then drops privileges and changes to uid 65535, and the default group for a tty (believed to be "tty", but not checked). So in my case if I use "ps" then I see the process running as user nobody and hence it cannot access the s2usb device which is permission uid:root, gid:uucp If your setup IS working then can you please examine the output of ps to determine what user/group gpsd is running as, because on my install it has dropped privs and subsequently cannot access the ttyUSBX device. There is no magic here and it's unrelated to hotplug - you can literally start the daemon from the command line and see this effect. A cursory glance at the code confirms that this is how it's supposed to work. If your permissions are different then I would like to understand how/why. (I can see no reason in the code why your setup should be different?) My patch simply makes it so that when the daemon drops root privs it changes to a user other than "nobody", ie "gpsd" which is a member of the uucp group
I posted the device info in comment #2 above, and yes, it works fine for me (as you noted, the way the code is intended to run). The device itself is opened by gpsd, and subsequent client access is via the socket setup by gpsd, not the device. So no, I don't think there's a problem with the way it is now, and I'm not really inclined to change it. If you need to access the device directly, then you need to be a member of the uucp group (and if that's what you're doing, then why are you running gpsd?). Conversely, if you're running gpsd, then you should be using the socket interface (or one of the many clients). You're always free to keep a modified version in your overlay.
I'm pretty sure you are still confusing which device you are talking about? I think you are now talking about the socket (/var/run/gpsd.sock) which gpsd creates? I'm talking about the ttyUSBX socket which is already created for us by udev (previously) The issue is as you agree - the device is created for us by some other rule with permission root:uucp. However, gpsd drops permissions and runs as nobody:tty (I asked you to check this on your system, but you didn't verify this yet?). So the end result (just read it, it should be obvious) is that gpsd cannot possibly access ttyUSBX? You are avoiding describing your config, but I *suspect* that you pass the device to gpsd on the command line as it starts up and possibly it therefore opens the serial port as root before dropping privs? (untested theory). In my case I am using udev to talk to the gpsd socket (/var/run/gpsd.sock), which then tries to open the newly available ttyUSBX device, but fails since it's running as user nobody:tty I really can't see why this should be different for you - I would be grateful if you could confirm *why* your setup works if it does so. I hope I have clearly shown why it should not, therefore if yours does work then it's because of some accidental quirk of your permissions and I need to try and understand why your system is doing this (I don't believe it should do so!) Seriously - it's not possible for nobody:tty (gpsd) to access device root:uucp (/dev/ttyUSBx) - QED something is different about your setup to what it should be by default
Look, I'm not the one who is confused here, nor am I avoiding anything. My setup isn't unique in any way, other than specific things in package.keywords, package.use, etc (see below for my desktop info). The upstream design/implementation actually works, on every box I've tried it on, from this amd64 desktop machine to a tiny x86 netbook. We've had issues in the past with gpsd hotplugging, but not any more. Certainly the latest version (2.39) works fine that way, ie, I plug it in and gpsd gets launched correctly. Then I run a client like xgps or gpsdrive and they both work. Where's the problem? Since it opens the device as root, it really doesn't matter what user/group the daemon drops privs to. Oh yeah, and it works just fine without USB (using the init script instead). Your proposed changes would add Yet Another system user, which is unnecessary at best, and possibly an increased security risk at worst. There's also the risk of breaking another package that makes any assumptions about those things. And as you can see below, gpsd has no problem opening the device and communicating with the actual GPS interface. So, if it doesn't work for you, then there's something weird/different about *your* system, not everyone else's. Which is another point I'm still not clear on; exactly what broken behavior are you seeing? Instead of trying to convince me that the *package* (either upstream or ebuild) is all wrong, why don't you try providing the information about your *problem* and I might be able to help. For example: 1) emerge --info and gps hardware info 2) package use flags and any relevant build or environment info 3) system logs showing what happens when you plug the device in, etc Lastly, if you're trying to develop your own gps client or do anything non-standard, then you should really take it up with the upstream developers. Thanks in advance. My desktop: Linux shiva 2.6.30.4 #1 SMP PREEMPT Sat Aug 8 08:34:37 PDT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ AuthenticAMD GNU/Linux # ls -l /dev/ttyUSB0 crw-rw---- 1 root uucp 188, 0 Aug 29 11:00 /dev/ttyUSB0 # emerge gpsd -v1p These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sci-geosciences/gpsd-2.39 USE="X dbus ntp usb -garmin -minimal -ocean -tntc" 0 kB [0] Log messages with USE=usb and hotplug: Aug 29 11:00:40 shiva usb 5-2: new full speed USB device using ohci_hcd and address 2 Aug 29 11:00:40 shiva usb 5-2: New USB device found, idVendor=067b, idProduct=2303 Aug 29 11:00:40 shiva usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Aug 29 11:00:40 shiva usb 5-2: configuration #1 chosen from 1 choice Aug 29 11:00:40 shiva usbcore: registered new interface driver usbserial Aug 29 11:00:40 shiva USB Serial support registered for generic Aug 29 11:00:40 shiva usbcore: registered new interface driver usbserial_generic Aug 29 11:00:40 shiva usbserial: USB Serial Driver core Aug 29 11:00:40 shiva USB Serial support registered for pl2303 Aug 29 11:00:40 shiva pl2303 5-2:1.0: pl2303 converter detected Aug 29 11:00:40 shiva usb 5-2: pl2303 converter now attached to ttyUSB0 Aug 29 11:00:40 shiva usbcore: registered new interface driver pl2303 Aug 29 11:00:40 shiva pl2303: Prolific PL2303 USB to serial adaptor driver Aug 29 11:00:40 shiva gpsd.hotplug: gpsd_control(action=add, arg=/dev/ttyUSB0) Aug 29 11:00:40 shiva gpsd.hotplug: socket /var/run/gpsd.sock doesn't exist Aug 29 11:00:40 shiva gpsd.hotplug: launching gpsd -F /var/run/gpsd.sock $ ps ax|grep gpsd 5737 ? S<sl 0:02 gpsd -F /var/run/gpsd.sock $ telnet localhost 2947 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. P GPSD,P=34.900983578 -120.430253145 D GPSD,D=2009-08-29T18:38:24.0Z b GPSD,B=4800 8 N 1 y GPSD,Y=EID6 1251571160.000 12:7 58 47 27 1:5 26 253 37 1:8 54 325 20 1:13 47 147 32 1:28 51 242 23 1:19 31 64 0 0:10 22 288 0 0:3 14 43 0 0:23 9 144 0 0:25 45 76 26 0:6 5 37 0 0:47 10 104 0 0: $ emerge --info Portage 2.2_rc33 (default/linux/amd64/2008.0, gcc-4.3.4, glibc-2.8_p20080602-r1, 2.6.30.4 x86_64) ================================================================= System uname: Linux-2.6.30.4-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4800+-with-gentoo-2.0.1 Timestamp of tree: Wed, 19 Aug 2009 09:15:02 +0000 distcc 3.1 x86_64-pc-linux-gnu [enabled] ccache version 2.4 [enabled] app-shells/bash: 4.0_p28 dev-java/java-config: 1.3.7-r1, 2.1.8-r1 dev-lang/python: 2.4.6, 2.5.4-r2, 2.6.2-r1, 3.1.1 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib64/fax /usr/share/bufrtables /usr/share/config /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg ccache distcc distlocks fixpackages multilib-strict parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://XXX/gentoo/" LANG="C" LDFLAGS="-Wl,-O1" LINGUAS="en_US en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://XXX/gentoo-portage" USE="3dnow X Xaw3d a52 aac aalib accessibility acl acpi ada alsa amd64 amrnb ansi ao artworkextra aspell avahi avi bitmap-fonts bluetooth bonobo browserplugin bzip2 cairo caps cddb cdparanoia cdr clamav cli cracklib crypt css cups curl daap dbus dga directfb divx4linux djvu dri dts dv dvd dvdr dvdread dynagraph emacs enchant encode evo exif faac faad fam fame fbcon ffmpeg firefox3 fits flac fontconfig fortran freetype freetype2 gb gd gdbm geos gif gimp glib gmp gnome gnutls gphoto2 gpm gps graphviz grass gs gstreamer gtk gtkhtml gtkspell guile hal howl iconv icq id3tag ieee1394 ifp imagemagick imap imlib inotify ipod ipv6 isdnlog jabber jack jasper java jbig jikes jpeg jpeg2k jpg junit ladspa lame lapack lash latex lcms ldap libnotify libsamplerate lirc lm_sensors logrotate mad midi mmx motif mp3 mp4 mpeg mplayer mtp mudflap multilib mysql mythtv nas nautilus ncurses netcdf nfs nls nolvmstatic nptlonly nsplugin numeric objc ogdi ogg oggvorbis opengl openmp oss pam pcre pda pdf perl phonon pkcs11 plotutils png policykit postgres pppd pulseaudio python qt3support qt4 quicktime readline reflection rtc ruby samba sasl sdl seamonkey session slp smartcard sndfile snmp spamassassin spell spl sse sse2 ssl subtitles svg sysfs taglib tcl tcpd theora threads tiff timidity tk truetype truetype-fonts type1-fonts unicode usb v4l v4l2 vcd vorbis wav wavpack wifi xanim xcb xext xine xml xorg xpm xulrunner xv xvid xvmc zeo zlib zvbi" ALSA_CARDS="emu10k1 hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_digest auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_connect proxy_http rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="directory canon casio fuji kodak polaroid ptp2 samsung spca50x" ELIBC="glibc" INPUT_DEVICES="keyboard mouse joystick evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US en" USERLAND="GNU" VIDEO_CARDS="fbdev radeon vesa v4l radeonhd" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 202625 [details] xgps screenshot Yes, it really works!
I am away and won't be back until next friday, but to answer a few points: "Since it opens the device as root, it really doesn't matter what user/group the daemon drops privs to. " I think you are confused on this point. if you use udev hotplugging then first the daemon drops privs and THEN it opens the device, so you are at best incorrect here. Now the root of the matter is that on *my* machine it drops privs to user nobody and I believe to group "tty" (need to check the group) Now you say: # ls -l /dev/ttyUSB0 crw-rw---- 1 root uucp 188, 0 Aug 29 11:00 /dev/ttyUSB0 So, clearly your gpsd process must be running either as user root, or group uucp (how could it possibly be anything else? Look at the permissions!) So my question is really if you could confirm which user/group your gpsd is running as. However you reply: $ ps ax|grep gpsd 5737 ? S<sl 0:02 gpsd -F /var/run/gpsd.sock I might be being dim, but this doesn't seem to answer the question as to what user gpsd is running as? To be clear I do essentially an identical set of steps to you, and in my case it reports an error when the python udev script tries to add the device to gpsd (you need to alter the python script to return the success/failure result, by default it throws the return value away). However, if I instead run gpsd so that it doesn't background itself then it remains running as root and in that case everything works fine Based on this evidence I worked through the code until I discovered that it drops privs and the rest became clear quite quickly (actually after the fact I noticed the docs on gpsd reminding you to check perms on the tty device...) It's very clear that I have a permissions problem in my case. I'm not clear why you don't feel it's peculiar that you *don't* have a permissions problem? Just look at the permissions on the device and on your gpsd process (it should NOT be running as root, so by definition it must be running as group uucp, question then becomes how this happens?) I am running openrc 0.4.3 here and udev-141. Permissions on most tty devices are root:tty, which is I believe why my gpsd process is likely picking up the wrong group perms (I need to check this though). I hope the problem is completely clear now? Somehow gpsd MUST end up running as group uucp - a quick glance at the code and you can see it guesses the group based on some heuristics, which makes it quite peculiar that the group is correct in your case and not in mine I am not near my machine for at least a week - could you please show what user/group your gpsd is running as when started by the python udev script? Thanks
It works just fine: $ ps -ef|grep gpsd nobody 10905 1 0 14:47 ? 00:00:00 gpsd -F /var/run/gpsd.sock
Clearly it works just fine the way it is. Is your device defined in the supplied gpsd udev rules? How about some logging info? I still can't help you until you supply some useful information and stop arguing with everything I say. Thanks in advance...
All my serial ports have group "uucp", whether USB-serial, ACM, or normal: $ ls -l /dev/ttyS* crw-rw---- 1 root uucp 4, 64 Aug 30 15:02 /dev/ttyS0 crw-rw---- 1 root uucp 4, 65 Aug 30 08:39 /dev/ttyS1 crw-rw---- 1 root uucp 4, 66 Aug 30 08:39 /dev/ttyS2 crw-rw---- 1 root uucp 4, 67 Aug 30 08:39 /dev/ttyS3 $ ls -l /dev/ttyACM0 crw-rw---- 1 root uucp 166, 0 Aug 30 15:05 /dev/ttyACM0 If you're getting group "tty" instead, then something sounds goofy in your udev rules. First try running gpsd with just the init script (ie, USE=-usb). When you plug it in, you should see the udev device creation, then you can verify the device perms and try starting it via the init script. Again, all the gpsd udev rules do is look at the ttyUSB devices and match against specific Vendor/Product IDs. When there's a match, the gpsd.hotplug script gets launched. If your device is not present in the rules file, then by all means add a rule for it.
"All my serial ports have group "uucp", whether USB-serial, ACM, or normal: $ ls -l /dev/ttyS* crw-rw---- 1 root uucp 4, 64 Aug 30 15:02 /dev/ttyS0" OK, well mine aren't, so this is the reason for the difference. I do wish you would just look at the code - you are treating me like an idiot when I have already stated than I'm debugging this having read the code... I'm not sure why you are arguing with me - the code clearly shows that it runs as the group given to the "default" tty owner, which in my case is not uucp and in your case is uucp. Clearly I'm absolutely correct in my assertion that I have a permission problem - please stop claiming black is white. The question is still why your tty's are all owned by uucp and mine aren't? I said already that I am running openrc-0.4.3 and udev 141 - can you confirm if you are on something newer or older? I am not back in the same country as this machine until friday, but I will have a look at the udev rules for general tty creation because this is where the difference now lies Seriously, gpsd just inherits the group perms of the default tty device, so if this isn't uucp then you are SOL to use gpsd with udev. (It has nothing to do with all the serial port udev stuff that you keep mentioning - all that does is run a python script to add the device to gpsd - if it can't be opened due to not having perms then you are stuffed) "If you're getting group "tty" instead, then something sounds goofy in your udev rules." Possibly - I will debug the udev rules next - however, they are stock udev 141 - what are you using? "First try running gpsd with just the init script (ie, USE=-usb). When you plug it in, you should see the udev device creation, then you can verify the device perms and try starting it via the init script." I don't really understand what you mean, nor see how this is relevant? gpsd doesn't create any devices?? There is no major difference starting it with the init script? (And additionally using USE=-usb means that you don't have any of the python udev scripts and hence the whole startup process is different, which completely negates the situation described?) "Again, all the gpsd udev rules do is look at the ttyUSB devices and match against specific Vendor/Product IDs. When there's a match, the gpsd.hotplug script gets launched." I agree - so, can we please stop talking about these? I have said quite a few times that this is nothing to do with this - it's to do with the perms of the gpsd process, nothing else... You keep bringing it back to these udev rules - seriously, it's nothing to do with them. "If your device is not present in the rules file, then by all means add a rule for it." Already said in the previous email that I am using a slightly modified python udev script to monitor all this, so by definition my rules must be working? Please lets forget about these rules and focus on the initial bug report (hint: permissions on the gpsd daemon and perms on the tty devices) Thanks for taking an interest, but can we please just focus on the bug report whihc is about the *permissions* and nothing to do with the gpsd udev rules, etc I will take a closer look at my udev setup for general tty devices, but this is where the difference is coming from.
OK, after adding some debugging into the code I finally spotted the real problem. Seems that if you don't have a device on the command line, then under linux it checks /dev/ttyS0 and sets the group to be the group which owns ttyS0. Additionally it would appear that if you have a serial port console enabled then the perms are set to be owned by root on the serial port: $ ls -al /dev/ttyS0 crw--w---- 1 root root 4, 64 Sep 4 15:57 /dev/ttyS0 So the end result is that starting gpsd gives: Sep 4 15:58:57 localhost user.notice gpsd[4108]: gpsd: Testing: /dev/ttyS0. changing to group 0 Sep 4 15:58:57 localhost user.notice gpsd[4108]: gpsd: running with effective group ID 0 Sep 4 15:58:57 localhost user.notice gpsd[4108]: gpsd: running with effective user ID 65534 When I plug in my BU-353 I get: Sep 4 16:00:45 localhost user.info kernel: [ 217.860580] usb 2-1: new full speed USB device using ohci_hcd and address 3 Sep 4 16:00:45 localhost user.info kernel: [ 218.078353] usb 2-1: configuration #1 chosen from 1 choice Sep 4 16:00:45 localhost user.info kernel: [ 218.080127] pl2303 2-1:1.0: pl2303 converter detected Sep 4 16:00:45 localhost user.info kernel: [ 218.102419] usb 2-1: pl2303 converter now attached to ttyUSB0 Sep 4 16:00:46 localhost daemon.info gpsd.hotplug: gpsd_control(action=add, arg=/dev/ttyUSB0) Sep 4 16:00:46 localhost user.notice gpsd[4108]: gpsd: control socket connect on 7 Sep 4 16:00:46 localhost daemon.info gpsd.hotplug: reached a running gpsd Sep 4 16:00:46 localhost user.notice gpsd[4108]: gpsd: <= control(7): +/dev/ttyUSB0\x0d Sep 4 16:00:46 localhost user.notice gpsd[4108]: gpsd: <= control(7): adding /dev/ttyUSB0 Sep 4 16:00:46 localhost user.notice gpsd[4108]: gpsd: opening GPS data source at '/dev/ttyUSB0' Sep 4 16:00:46 localhost user.err gpsd[4108]: gpsd: device open failed: Permission denied - retrying read-only Sep 4 16:00:46 localhost user.err gpsd[4108]: gpsd: read-only device open failed: Permission denied Sep 4 16:00:46 localhost user.notice gpsd[4108]: gpsd: select waits Sep 4 16:00:46 localhost daemon.info gpsd.hotplug: gpsd_control result: ERROR So I have updated the problem description to be: "gpsd runs with wrong group permissions when serial console enabled". Note that this is mainly going to hit server users and embedded appliances - hopefully both a reasonably interesting category of users... Therefore the options would seem to be: - patch to allow a configurable device to test (ugly and error prone) - patch to allow a hard coded group (gpsd already has a "run as user" option) - patch to setup a new user with a known group and set this as the hardcoded user (already done, see above). This seems the most conventional route, but doesn't seem popular Any thoughts on the best way to tackle this?
First, I'm not sure what you mean by "serial console enabled" - are you talking the kernel option or a physical device? I guess I haven't connected a gps to anything with a serial console; I've used a CF gps device on a Sharp zaurus running open embedded, but the console is not normally enabled. What I'd prefer is to keep the normal gpsd config the same as upstream, and based on what you've found, it sounds like you should be able to achieve your settings via an additional udev rule. It also seems like something that should only be enabled by the user; if you can do it with a udev rule and/or some conditional code in the ebuild, then we can add a USE flag for it. Otherwise it sounds like an upstream use-case-plus-patch proposal...
I confirm the behaviour described by Ed, and possibly extend its scope. I'm using a fresh gpsd-2.39-r1 (X dbus gpsd_user pl2303 usb -garmin -minimal -ntp -ocean -tntc) and a “standard” SiRF III GPS behind a PL2303 adapter. I have no ttyS* device to start with on my test computer. When I plug the GPS in, I have the following in my logs (gpsd is not previously running): Mar 10 00:51:01 gloduk kernel: usb 4-1: new full speed USB device using ohci_hcd and address 11 Mar 10 00:51:01 gloduk kernel: usb 4-1: configuration #1 chosen from 1 choice Mar 10 00:51:01 gloduk kernel: pl2303 4-1:1.0: pl2303 converter detected Mar 10 00:51:01 gloduk kernel: usb 4-1: pl2303 converter now attached to ttyUSB0 Mar 10 00:51:01 gloduk gpsd.hotplug: gpsd_control(action=add, arg=/dev/ttyUSB0) Mar 10 00:51:01 gloduk gpsd.hotplug: socket /var/run/gpsd.sock creation failure: [Errno 111] Connection refused Mar 10 00:51:01 gloduk gpsd.hotplug: launching gpsd -F /var/run/gpsd.sock Mar 10 00:51:01 gloduk gpsd[28077]: gpsd: device open failed: Permission denied - retrying read-only Mar 10 00:51:01 gloduk gpsd[28077]: gpsd: read-only device open failed: Permission denied And gpsd runs as user “gpsd” while ttuUSB0 belongs to root:uucp. gpsd 28077 0.0 0.1 5676 1584 ? S<s 00:51 0:00 gpsd -F /var/run/gpsd.sock crw-rw---- 1 root uucp 188, 0 2010-03-10 00:51 /dev/ttyUSB0 At this point, of course, no gpsd-based tool finds any GPS. Then I create a fake /dev/ttyS0 which belongs to group uucp (it's really a /dev/null, but this doesn't change the point here) shtrom@gloduk:~$ sudo mknod /dev/ttyS0 c 0 0 shtrom@gloduk:~$ sudo chown root:uucp /dev/ttyS0 I kill gpsd to be in the same situation as before, then plug the GPS device again. Mar 10 00:55:17 gloduk kernel: usb 4-1: new full speed USB device using ohci_hcd and address 12 Mar 10 00:55:17 gloduk kernel: usb 4-1: configuration #1 chosen from 1 choice Mar 10 00:55:17 gloduk kernel: pl2303 4-1:1.0: pl2303 converter detected Mar 10 00:55:17 gloduk kernel: usb 4-1: pl2303 converter now attached to ttyUSB0 Mar 10 00:55:18 gloduk gpsd.hotplug: gpsd_control(action=add, arg=/dev/ttyUSB0) Mar 10 00:55:18 gloduk gpsd.hotplug: socket /var/run/gpsd.sock creation failure: [Errno 111] Connection refused Mar 10 00:55:18 gloduk gpsd.hotplug: launching gpsd -F /var/run/gpsd.sock This time, everything works, as tested with gpsmon. This raises the question, in my opinion, of why /dev/ttyUSB0 is own by group uucp? In the case of a GPS (or a pontential GPS, as it can only be acertained after gpsd has openned and read the device), wouldn't it be advisable to have all these devices given the same group as that GPS runs as (or has been compiled to run as)? A simple udev rule could do the trick.
(In reply to comment #17) ttyUSB* is a serial device. the fact that it is actually connected to a GPS doesn't matter. the hardware is a simple serial device. thus the default udev rules kick in which assigns it to the uucp group. gpsd-2.96-r1 and newer explicitly configure gpsd to use the user "gpsd" and the group "uucp", so in theory, this issue should be fixed.
Please close this bug - you (Spanky) have I think already committed the new ebuild for the 3.3 version (bug 380883), so whilst this same bug has re-occurred and then be re-fixed in the gpsd code (sigh), I think we are past caring about such old versions now?
Closing as this is fixed in 3.x series for good.
