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 [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
