Re: -rw-rw-rw- 1 root 8025 Aug 24 04:10 /tmp/.lsof_dev_cache

[abe () vic cc purdue edu (Vic Abell)]

In message <199508242356.TAA14896 () Collatz McRCIM McGill EDU> der Mouse writes:
> I am less confident than Victor Abell is that this isn't a security
> hazard.  However, I have never investigated in enough detail to make
> any confident pronouncements either way.  If you're paranoid, you can
> use -Di to make it ignore the cache, -Du/some/other/path to make it put
> it somewhere else, or frob the source....

If I left the impression that I was confident this isn't a potential
security hazard, I was foolish.  I worried about it when I installed
the feature, I was worried enough about it to accompany it with
documentation, and I'm still worried about it.  However, in my
opinion the performance payoff is just too great to ignore having
this feature.  I've tried as hard as I know to make it as safe as
possible.

In two messages Darren Reed <avalon () coombs anu edu au> writes:
> The threat is it:
>       (a) doesn't use O_EXCL to open the file
>       (b) uses chown instead of fchown
>
> ...
>
> People designing setuid-root programs or programs in general which perform
> priviledged operations and need temporary files should consider using a
> non-public access directory as the temp. file location.
>
> ...
>
> Is there any reason why it is chown'd at all ?

First, lsof can't use O_EXCL, because the file may be owned by
someone else.  If /tmp has the sticky bit, lsof can't even remove
the file.  The best lsof can do when the file must be rebuilt and
exists is to open it with O_TRUNC.  Lsof may not own the file for
several reasons: 1) lsof generally runs without setuid permission,
so a previous user of lsof (not the current one) created the file;
and 2) the intent of changing ownership was to avoid having a root-
owned file in /tmp in the first place.

As I have said in several replies to the original post, at revision
3.40 lsof uses fchown(), wherever possible.  Some older Unix dialects
(e.g., SCO below Release 5.0) don't support fchown().

Finally, the file is in /tmp by default for a number of reasons: 1)
it is the only common place I could find for the 25+ Unix dialects that
lsof supports; 2) lsof may not have enough special permission to put
it anyplace else; and 3) the installation procedure becomes much more
complicated when the installer must build and secure a special place
for the device cache file.

On the other hand, if the installer really wants to put the device
cache file in a special place, the HASDCACHE definition enables that.

> Dave Sill <de5 () sws5 CTD ORNL GOV> writes:
>
> The only risk I see is that someone could edit out certain
> devices.

This has some risk.  On some Unix dialects sockets are identified
by the major device number from an entry in /dev.  Hence, a carefully
determined invader could delete the socket device, while leaving
the rest of the device cache file consistent (counts and checksum),
so that lsof couldn't recognize socket files.

When a serious threat from socket files calls for lsof, use -Di to
avoid the device cache file.

Vic Abell