From owner-freebsd-hackers Tue Nov 4 15:28:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17703 for hackers-outgoing; Tue, 4 Nov 1997 15:28:40 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17691 for ; Tue, 4 Nov 1997 15:28:32 -0800 (PST) (envelope-from brandon@roguetrader.com) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id QAA01329; Tue, 4 Nov 1997 16:27:41 -0700 (MST) Date: Tue, 4 Nov 1997 16:27:40 -0700 (MST) From: Brandon Gillespie To: Tom cc: James Raynard , freebsd-hackers@FreeBSD.ORG Subject: Re: Suggested addition to /etc/security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 1 Nov 1997, Tom wrote: > On Thu, 30 Oct 1997, James Raynard wrote: > > > > echo "checking for invalid user or group ids:" > > > > > > find / -nouser -nogroup > > How does this check improve security? It depends upon how your system is setup. If _ALL_ of the files a user will ever use are contained within their home directory, then this check does nothing. However, many systems (myself included, which is what made me think of it) don't do this. I have several projects running on my server, and people own files througout several different filesystems. If I remove a user--these files are still owned by them. This in itself isn't a problem, until you consider that the add user programs (those I've checked, ''pw'' included) default to reusing user ids! (this should also be changed--its not like we dont have enough of a range for the general case). So if I nix somebody, then a week later add another user which gets the old guy's uid--he also gets all the files and programs of the old guy. While in general this isn't a big security issue, its still a problem (could be a very BIG problem on some systems). Consider a server where (for whatever reason) a private file was stored in a location other than the user's home directory. Because of the situation as explained above, another user is then assigned their uid. They then have access to these files and YOU are suddenly liable for it (sure, this scenario isn't bullet proof, but it does demonstrate the concerns). -Brandon Gillespie