UNIX for Dummies Questions & Answers

Perderabo has a really soild point - not that ptrace is good or bad.

A major goal of a sys admin is provide access to data and keep data safe. Anything that compromises a system, or prevents users from getting to a directory - on a production machine - is to be avoided. Even if it is just for a few minutes.

Changing protections on a directory or unplugging routers, or running interesting code is fine (whatever) if you are the only user on the box. Othwerwise exhaust all of the non-disruptive methods first, before you start messing up user's data.

Try the destructive stuff on Saturday at 4:00pm. Or - back up the system, then lock everybody out at 7:00pm, check cron jobs to see if you're gonna cause a problem, reset the system clock And see if it happens again.

I'd also backup/copy all of the files out of that tree to a safe location. And at a time so backup/copy just completes before 4:00pm everyday -- until you find the cause and correct it. You can restore the directory & files at 4:01 if you need to.

If you are not having to restore files now, then the loss of the files isn't that critical.

Thanks Everybody for guiding me with different ideas. Yesterday, We found the process which was deleting the Directory. I was very much tempted to use strace, trace as suggested by Driver, but as Perderabo mentioned there would be some risk, which I chose not to take on production system.
We got hundreds of automated /manual processes running all the time on production system. So Unplugging the system was out of questions , or cannot replace rm or rmdir, since many of these processes are dependent on each other by deleting /creating status file. Even cannot change permission on the directory as many processes are continously uses it.

I did not have unix admin authority, since we are just ERP developer. Hence I could not see in Crontab directory under /var/spool/crontab/??/??
After doing many different tests, following simple approch was successful which was suggested by Perderabo.

We created a subdirectory tmp and did chmod 000 tmp using my userid. At 4:00 pm, all files were deleted except tmp. That proved that 'root' is not the culprit. But whoever deleted all other files must have permission to delete for every user in the system. Who that can be??. Group User -- bingo..(!!But, still at this point, I was not very much sure!) So, this simple test narrowed down to the culprit. Now, 2nd task was which process by group Id is deleting the directory??. We tried to capture all the processes by putting (ps -ef | grep groupid) in a loop during 4:00 pm time.. but we could not capture any processes by Group Id! May be because the process was very short lived!!. I was confused, did not know what to do..!!, Went back to unix admin, tried to discuss with them, what I did and also mentioned about pstrace, strace, ls -lu etc!. Finally, they came up with the exact process run by group id set in cronjobs.


One more Q for all the experts. "ls -lu /usr/bin/rm" will give me the last access date/time. Is it possible to know by any way, the user that accesed 'rm' at that time?.
Perderabo mentioned in previous post--
===============================
Deleting a directory requires write permission to the parent directory. By varying the permissions on that parent, you should be able to nail down the uid involved.
==============================

How do we nail down UID that tries to delete a directory having no permission??

Thanks
DM

You get a list of candidates. Maybe that is every user on the system. Or maybe you can limit it down as you did. Maybe it's only those users who are a member of a particular group.

Let's say that your candidates are joe, harry, and fred.

Go to the parent directory.

mkdir fred.d
touch fred.d/file
chmod 700 fred.d fred.d/file
chown fred fred.d fred.d/file

Now only fred (or root) can delete "file". And no one can delete fred.d until after "file" is gone. So if fred tries to remove the parent directory, he will succeed with fred.d/file and then fred.d. But no one else could.

Naturally, you also make a joe.d and a harry.d as well. With most unix systems, chown is restricted to root. You will need root's help with this.