On Thu, 2007-07-19 at 09:24 -0400, John D. Ramsdell wrote:
[root@goo fork]# ausearch -i -p 1160 > autrace.txt
[root@goo fork]# grep clone strace.txt
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7efb708) = 1122
[root@goo fork]# grep clone autrace.txt
type=SYSCALL msg=audit(07/19/2007 09:16:02.350:848) : arch=i386 syscall=clone success=yes
exit=1161 a0=1200011 a1=0 a2=0 a3=0 items=0 ppid=1158 pid=1160 auid=ramsdell uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 comm=fork
exe=/home/ramsdell/proj/fork/fork subj=user_u:system_r:unconfined_t:s0 key=(null)
Actually it's a problem with mapping things. The flags are in a0. If
you look at the clone man page they talk about sys_clone at the bottom
(which is the actual call, whereas cone is just a library function on
top of the call) and they state the the ordering for sys_clone is
different. The kernel function is actually
asmlinkage long
sys_clone(unsigned long clone_flags, unsigned long newsp,
void __user *parent_tid, void __user *child_tid, struct
pt_regs *regs)
So the flags are actually coming in the first argument. To verify check
#define CLONE_CHILD_SETTID 0x01000000
#define CLONE_CHILD_CLEARTID 0x00200000
#define SIGCHLD 0x00000011
Which just so happens to be 0x01200011
and a0 just so happen to be 1200011
But it's just a difference between the library call 'clone' that the
application makes and the actual syscall glibc translates that to
sys_clone and the ordering of the flags.
-Eric