From owner-freebsd-ports  Thu Apr  6 10:12:24 1995
Return-Path: ports-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id KAA02329
          for ports-outgoing; Thu, 6 Apr 1995 10:12:24 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA02323
          ; Thu, 6 Apr 1995 10:12:23 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
	id AA13795; Thu, 6 Apr 95 11:04:03 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9504061704.AA13795@cs.weber.edu>
Subject: Re: lsof 3.25 now available for fbsd 2.0
To: mbarkah@teton.Mines.Colorado.EDU (Ade Barkah)
Date: Thu, 6 Apr 95 11:04:02 MDT
Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org,
        ports@FreeBSD.org
In-Reply-To: <9504061650.AA42466@teton.Mines.Colorado.EDU> from "Ade Barkah" at Apr 6, 95 10:50:10 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: ports-owner@FreeBSD.org
Precedence: bulk

> >> ... The version uploaded was compiled with -DHASSECURITY which 
> >> restricts non-priviledged users from listing other people's open 
> >> files. ...
> >
> > Does this make sense?  I'm perfectly able to look at any open file
> > with fstat(1).  So why restrict lsof to less than fstat can do?
> 
> Well, lsof is capable in displaying much more than fstat by default, 
> to the point that other user's privacy might be invaded, so I decided 
> to restrict the output.

The "peek" program offers a similar hole.

UNIX-type systems use a "security through obscurity model", the theory
being that you are statistically unlikely to find a file name if you
are unable to iterate a directory, so the file can be otherwise able
to be read but still be secure.

Being able to see what files other people have open is the same as
allowing them to iterate at least one file in that directory.

The "peek" problem is a little less pronounced, in that it will give
current working directories, and you have to get the file name from
ps'ing a command line option to vi or some other program.

Weber recently had a problem with this, since user's top level
directories were open for read-but-not iterate.  The intent was to
allow the creation of symlinks in a sticky directory to the user's
home directory to allow people to link their own home pages in
(a CGI script was used to generate the list from ls data about the
link owner).  Clearly this wouldn't work under BSD with its broken
symlink ownership (the owner is listed, not the link name, to prevent
abuse).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.