Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

So I wanted to know which process is creating a directory ']' in my root. I was assuming this is some typo in some script. So I set up an audit for that directory, very similarly as shown on This question.

The next day I checked my logs and found out that the directory has been created again, and it has been logged by audit. But all I can tell from this output, is that root created it.

output:

type=SYSCALL msg=audit(26.04.2013 06:25:20.275:85) : arch=i386 syscall=mkdir success=yes exit=0 a0=bfd02ea5 a1=1ed a2=bfd02ea5 a3=bfd025b8 items=2 ppid=24114 pid=24115 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=4294967295 comm=mkdir exe=/bin/mkdir key=weird 

Broken to lines :

type=SYSCALL 
msg=audit(26.04.2013 06:25:20.275:85) : 
arch=i386 
syscall=mkdir 
success=yes 
exit=0 a0=bfd02ea5 
a1=1ed a2=bfd02ea5 a3=bfd025b8 
items=2 ppid=24114 pid=24115 
auid=unset 
uid=root 
gid=root 
euid=root 
suid=root 
fsuid=root 
egid=root 
sgid=root 
fsgid=root 
tty=(none) 
ses=4294967295 
comm=mkdir 
exe=/bin/mkdir 
key=weird 

I would like to know which script issues this command as root. Is that possible? The process using that PPID is no longer running.

share|improve this question

2 Answers 2

up vote 1 down vote accepted

From this output alone, you can't determine what program called the mkdir command.

If you have BSD process accounting, the following command shows which program had PID 24114:

dump-acct /var/log/account/pacct | awk -F '|' '$10 ~ / 24114 / {print}'

This is probably sh. Column 10 (with | as the separator) contains the PID of the recorded process followed by its PPID, so repeat the search with the PPID to see what program invoked sh and so on. You also get to know what time the process started, which may help figure out which cron job this was.

With auditd alone, you need to record not only the mkdir call but all accesses to that directory, so as to record the commands that change to the directory or access files in it. If the directory is created but nothing else accesses it, I don't think auditd alone is sufficient to figure this out.

share|improve this answer
    
Made some progress, but still not at the root-cause :P now i know it is bash.. just not which script :P bash |v3| 0.00| 0.00| 7.00| 0| 0| 5856.00| 0.00| 31965 31963|Fri May 3 06:25:13 2013 And parent of that is sshd. Parent of that gives nothing anymore . :P –  Gjordis May 3 '13 at 6:17
    
Ok, parent of that was still running =) Thanks, wish i could accept both answers, since needed them both for this. –  Gjordis May 3 '13 at 6:21

Assuming this is caused by a script started by cron you could trace all crond-children:

strace -p $CRONPID -f -o /path/to/cron-strace.log -e trace=mkdir

This should lead to output like this:

Process 3584 attached
Process 18227 attached
[pid 18227] execve("./testscript", ["./testscript"], [/* 100 vars */]) = 0
Process 18228 attached
[pid 18228] execve("/usr/bin/mkdir", ["mkdir", "/home/hl/tmp/strace-testdir"], ...) = 0
[pid 18228] mkdir("/home/hl/tmp/strace-testdir", 0777) = 0

strace slows script execution down, of course, but that should normally not be a problem.

share|improve this answer
    
I dont have an enviromental variable for cron's PID. You say that it slows script execution down, so will this monitor the cron execution? –  Gjordis Apr 26 '13 at 6:18
    
@Gjordis Of course, you don't have this enviromental variable. Noone has. strace monitors all system calls (all jumps into the kernel). As neither scripts can be started without them nor directories can be created, this reliably shows what's up. –  Hauke Laging Apr 26 '13 at 6:30
    
Ok, so now i have this attached to my /usr/sbin/cron. So when a child process of cron uses mkdir, it should log it? Well see what happend tomorrow 6.25 –  Gjordis Apr 26 '13 at 6:46
    
@Gjordis Yes, it should. –  Hauke Laging Apr 26 '13 at 6:50
    
Good try, apparently not a cronjob, since that particular mkdir did not make into the log. Thanks for the good command anyway. +1 –  Gjordis Apr 29 '13 at 5:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.