From owner-freebsd-hackers Mon Jun 4 12:54:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 5B90537B401 for ; Mon, 4 Jun 2001 12:54:30 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f54JsNg80223; Mon, 4 Jun 2001 12:54:23 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 4 Jun 2001 12:54:23 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gersh Cc: Rich Morin , hackers@FreeBSD.ORG Subject: Re: speeding up /etc/security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Let me turn it around and say that process accounting should be only one of a set of actions that can be emitted from the kernel and recorded somewhere. On Mon, 4 Jun 2001, Gersh wrote: > What about something like what process accounting does? > > It would be trivial to update a file (say /var/db/setxid) > whenever certian chmod / fchmod actions are taken. > > If it only happened when chmod/fchmod actions happened that > effected setxid stauts it should not impact performence to much either > IMHO. > > I think that the real thing to consid with a approach like this is. > > 1) How useful would it be. > 2) Because it would be used for something security relevant the > "database" file would need to remain secure at all times. > > On Mon, 4 Jun 2001, Matthew Jacob wrote: > > > > > That's an interesting question. > > > > A couple of ideas: > > > > a) I wonder of RWatson's ACL stuff could help here? > > > > b) This problem cries for a DMAPI type solution- you could have a daemon that > > monitors all creats/chmods and retains knowledge of the filenames for all > > SUID/SGID creats/chmods- this way /etc/security would simply summarize the > > current list and could be run any time. > > > > > /etc/security takes a number of hours to run on my system. The problem > > > is that I have some very large mounted file systems and the code to look > > > for setuid files wants to walk through them all. I recoded the check in > > > Perl, but it ran at about the same speed. I have considered reworking > > > the code to do the file systems in parallel, but I thought I should ask > > > here first. Comments? Suggestions? > > > > > > -r > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message