[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tiger-devel] [RFC] check_finddeleted

From: Ryan Bradetich
Subject: Re: [Tiger-devel] [RFC] check_finddeleted
Date: Wed, 07 Jan 2004 13:47:04 -0700

Hello Nicolas,

> I actually working on an awk script (attached).
> It should be ready for the selection of suspected process, but there is
> still work on the reporting part.
> I choose to implement it with awk to get the full command name with
> lsof. But the reporting part could be a completly separated function
> wich receive a list of pid (reparsing the command name won't be time
> consuming because there isn't a lot of reports). So I can do it in a more
> pure shell fashion.
> I have some questions on what should be its behaviour:
> A - servers using a deleted file are more critical
>   actually, there is a distinction between:
>     *  processes using a deleted file and listenning
>     *  processes using a deleted file and having one of its children
>        listenning
>     *  processes using a deleted file
>   Should we keep those three classes? Should we add a distinction for
>   processes using a deleted file and having its parent listenning, or
>   more generally processes that have a listenning process in their
>   group session.
>   I would prefer having those two classes:
>     * processes using a deleted file and being in the session of a
>       listenning process.
>     * processes using a deleted file.
>   (processes using a deleted file and listenning could also be kept, my
>    point is mostly on the "having its children listenning" and not other
>    "familly members" restriction)

I like the second method better.  I should really go read the paper Javi
modeled the report after to make sure there is not a good reason to
seperate them out more ... but simplier is better :)

>   Those classes would be reported as:
>     * FAIL the process "name" (pid,user,group?) of the server "name" 
> (pid,user,group?) is using a deleted file.
>     * WARN the process "name" (pid,user,group?) is using a deleted file.
>   Should we report the group?

group as in process id group?

> B - Which name of process to report
>   Actually, depending on the class, either the 8 letters truncated
>   command name from lsof is reported, or the executable name with
>   arguments (from ps -o cmd).

This is not completely portable either :( This fails on HP-UX.

        $ ps -o cmd
        ps: illegal option -- o
        usage: ps [-edaflP] [-u ulist] [-g glist] [-p plist] [-t tlist] [-R

I can get this to work by the following:

        $ export UNIX95=1
        $ ps -o args

but the output is truncated to a certain length.  The only way I know of
to get the full command length is only available in HP-UX 11.11 where
they added a -x option to the ps command.

As different side note ... the command-line can be changed, so ps is not
the best way to get the process name. There are a several programs that
I know of that do this ... sshd, postgres, etc.

        $ ps -e -o cmd | grep sshd
        sshd: rbrad [priv]
        sshd: address@hidden/4
        grep sshd

        $ ps -e -o cmd | grep postgres:
        postgres: stats buffer process
        postgres: stats collector process
        postgres: rbrad vsm [local] idle
        grep postgres:

Not sure if this matters ... but wanted let you know there might be
problems on other operating systems and with some programs.

>   Cons of "ps -o cmd":
>     * can be very long
>     * It can also be very different for scripts (a "test.py" python
>       script will be displayed "python test.py").
>   Pros:
>     * probably safer (the executable path is included)
>     * arguments can also be interesting for the security.
>   In the first classe proposed above, a mix of both could be done (short
>   command for the process name and executable name + args for the
>   session leader name)
> C - unit testing
>   To test my awk script, I've done some small python scripts that use
>   deleted file and listen.
>   Do you think:
>     * it could be interresting to keep them
>     * it could be possible to add some tests for other scripts for unit
>       testing (note that those scripts could be dangerous, and should be
>       use only for testing, and should probably not be distributed. e.g.
>       a script that would test if clear text passwords are detected and
>       temporarily add a clear text password)

I think unit testing is important and have found most of the bugs by
testing tiger against HP's coporate security guidelines.  I have been
trying to figure out a good way to incoporate a test suite also.  :)

> D - portability
>   do you think there is portability issue with this awk script?
>   apart from awk, I will use the same commands: lsof and probably ps.

oops ... I answered part of this question above.  I will test out the
awk script on HP-UX later today and see if I can get it to work.  Thanks
for the script :)

>   Is a pure shell code preferable?

It make it easier to port and is more inline with the tiger philsophy,
but honestly doesn't matter to me.

> E - is it resonnable to provide some tiger.ignore default for
>     check_finddeleted
>   I'm thinking of apache and gconf.
>   I also get some rare reports for mutt or aptitude.

I would personally like to use the tiger.ignore as little as possible as
it could hide data :)  if your proposal to update check_finddeleted
solves the problem then excellent :)  That being said ... if we need the
filters, then lets add them to the tiger.default.

> Regarding Ryan's recent mails:
>   Should I open a task in savannah for this? (and is a task the more
>   appropriate section?)

It would be nice :)  If we track projects we are working on more
publicly then maybe we won't duplicate effort :)  

I think this sounds like task item to me.

>   Is there a way to be notified for new tasks, bugs, or patches
>   (any pointer on the savannah's tools?)

Not sure.  I got notified but that is probabaly because it was me
submitting the bugs and the were assigned to me.  I am still playing
around with the tools and trying to understand them as well :)

There is 1 bug in the tools you should be aware of (I sent a private
email to Javi with this info already) but the new task link does not
work.  Use this link to add a new task:


> Best Wishes,

You too!

- Ryan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]