This means Kismet will only work from 'su -'. /usr/doc/kismet-2004.04.1/README.gz says that kismet should be installed with make suidinstall instead of make install to avoid this fatal error. Systems with multiple users should not use suidinstall, but for many users with laptops while their card is in rfmon it can't accept connections from other users unless they are connected to more than one interface. Reproducible: Always Steps to Reproduce: 1. $ kismet<enter> 2. 3. Actual Results: $ kismet Server options: none Client options: none Starting server... Waiting for server to start before startuing UI... Will drop privs to arosboro (1000) gid 100 FATAL: Unable to set up pidfile /var/run/kismet_server.pid, unlink() failed: Permission denied Expected Results: kismet's gui would eventally load and my network would be detected. I have a cisco aironet 352 using kernel 2.6.4 drivers which works fine from root. This is my first bug entry :)
I definitely do not intend to install another binary suid root by default. Just not gonna happen. Doing "su -" is an inconvenience, but none the less we should not be installing kismet suid root by default. If you want to attach an ebuild that uses some meaningful USE flag to enable this functionality, i'd consider it. Even then i'm wary.
My .02, I think that you should be root if you're setting your card into RFMON. Considering it's changing the usability of a piece of hardware. I have no issues su'ing root and then loading up kismet. If you dont want to always 'su -' I would possibly suggest using sudo to be able to start up kismet?
I agree 100% with latexer. Suggest closing as WONTFIX.
Done.
