Dan,
You write:
>
> Package: lsof
> Version: 4.77.dfsg.1-3
> Severity: normal
> File: /usr/bin/lsof
>
> User "proxy" cannot list its open files
> # lsof D*
> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
> wwwoffled 11539 proxy 5u REG 3,77 0 653903
> DXV-GOdRTzPdegvyZgbZPLQ
> wwwoffled 11543 proxy 5u REG 3,77 0 4474
> DEjKDzG0q-Ak4oqnGn7AiZg
> wwwoffled 11548 proxy 3u REG 3,77 0 271870
> DvzlSQhBMcHzWgmjxmtJa7g
> # su -c 'lsof D*' proxy
> # su -c 'lsof D*' root
> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
> wwwoffled 11543 proxy 5u REG 3,77 0 4474
> DEjKDzG0q-Ak4oqnGn7AiZg
> wwwoffled 11562 proxy 3u REG 3,77 2844 271876
> Df8+e8MLDaaASTfJxIxdR-w
> wwwoffled 11571 proxy 3u REG 3,77 0 271882
> D6y10cktvFNA9JwF-vni5pg
>
> I read the very complicated man page.
Please also read the lsof documentation on reporting bugs in the
"Bug Reports" section of the 00README file of the lsof source
distribution. It's important to download the source distribution
and read its documentation before sending a bug report to me.
> # su -c id proxy
> uid=13(proxy) gid=13(proxy) groups=13(proxy)
> Even when I do
> # su - proxy
> # cd dir
> # lsof D*
> it shows nothing.
> # su -c set proxy|grep ID=
> EUID=13
> UID=13...
>
> Wait
> Second, by default it creates a user-readable and
> user-writable device
> cache file in the home directory of the real user ID that
> executes lsof.
> $ grep proxy /etc/passwd
> proxy:x:13:13:proxy:/bin:/bin/sh
> Well how about printing an error message when you can't write in /bin!
If you really are talking about Linux, lsof never writes a device
cache file for that UNIX dialect. That's documented in the 00DCACHE
file of the lsof source distribution and apparent in the help output,
where no "-D" option is listed.
When lsof does support a device cache file and can't write to it,
lsof issues a warning message to STDERR -- e.g., on Solaris 9:
./lsof -Du/bin/xxxxx > /dev/null
lsof: WARNING: access /bin/xxxxx: No such file or directory
lsof: WARNING: can't open /bin/xxxxx: Permission denied
> Wait,
> # su - proxy
> $ cd /tmp
> $ cat>m&
> $ lsof m #works, so I don't know what is the problem. Must be same
> process tree maybe? Didn't need -Di and still worked.
Again, guessing that you are using Linux, you should probably determine
what process owns the /proc/<PID> directories and subdirectories of the
"proxy" processes in question. If it's not "proxy", then lsof running
under the "proxy" UID won't be able to read the information in those
directories.
Vic
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
