I really wish there could be a USE flag which would allow lsof to have full functionality for normal users without any other requirement (like sudo). I realize this might be considered a security risk, but I'd sure appreciate the option to live with the risk. I looked at the ebuild and the patch and am not sure what's the right approach or I'd have attempted to modify the ebuild. The easiest approach that comes to mind is to include an additional optional patch that would disable SECURITY. Reproducible: Always Steps to Reproduce: Sorry for no ebuild mods, if my approach seems reasonable, I can come up with that and attach it.
you should be able to create an /etc/portage/bashrc file that automatically sets the setuid bit when the lsof package is installed. cant say this kind of behavior sits well with me at all as a standard ebuild option. especially when we invest so much time in scrubbing set*id perms from the system.
Well, adding set-uid alone doesn't do it because HASSECURITY wires the binary to disallow access to info on all files, regardless of the set-UID: -rwxr-xr-x 1 root root 100636 2008-11-21 18:38 /usr/bin/lsof lsof -v 2>&1 | grep 'list all files' Only root can list all files, but anyone can list socket files. chmod u+s /usr/bin/lsof lsof -v 2>&1 | grep 'list all files' Only root can list all files, but anyone can list socket files. and behavior matches in that a non-root user cannot see anything even if the executable is set-uid. If you create the executable with HASSECURITY disabled and install it without set-uid, you get nastiness like: $ lsof -p 1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME init 1 root cwd unknown /proc/1/cwd (readlink: Permission denied) init 1 root rtd unknown /proc/1/root (readlink: Permission denied) init 1 root txt unknown /proc/1/exe (readlink: Permission denied) init 1 root NOFD /proc/1/fd (opendir: Permission denied) I'm very sympathetic to a desire to minimize set-uid. I guess the best approach is to leave things as they are and use sudo to gain root for this. I'm including all this just for the record in case it comes up sometime in the future.
you didnt clearly articulate a compile-only option in your original report. there seems to be one by your usage of caps and HASSECURITY. does building with CPPFLAGS=-UHASSECURITY work ?
