syscall record for mq_unlink

syscall record for mq_unlink

[Michael C Thompson]

Hey Steve,

So, Happy Thanksgiving, is this a bug? :P

Audit record:
type=SYSCALL msg=audit(1164127960.194:49): arch=c000003e syscall=241 
success=yes exit=0 a0=2aaaaab2171d a1=2aaaaab2171c a2=7fff69a6cab8 
a3=2aaaafb31188 items=3 ppid=1758 pid=1791 auid=4294967295 uid=0 gid=0 
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="python" 
exe="/usr/bin/python" subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)
type=CWD msg=audit(1164127960.194:49): 
cwd="/rhcc/lspp/tests/LTP/ltp-merged/testcases/kernel/security/mls/tests/framework"
type=PATH msg=audit(1164127960.194:49): item=0 name="-RNHJnfkU"
type=PATH msg=audit(1164127960.194:49): item=1 name=(null) inode=7385 
dev=00:0d mode=0100755 ouid=0 ogid=0 rdev=00:00 
obj=abat_u:object_r:abat_tmpfs_t:s0
type=PATH msg=audit(1164127960.194:49): item=2 name=(null) inode=338 
dev=00:0d mode=041777 ouid=0 ogid=0 rdev=00:00 
obj=system_u:object_r:tmpfs_t:s15:c0.c1023

The syscall prototype in the kernel is as follows:
asmlinkage long sys_mq_unlink(const char __user *u_name)

The function all is:
ret = mq_unlink(msgqid);

The value of char *msgqid is:
2aaaaab2171c

So, the question is:
Why is a0=(msgqid)+1, and why is a1=(msgqid)

I am not sure if this is some crazy "feature" or if this is a real bug. 
I know there are some syscalls that differ from the glibc-level calls, 
but this one violates the function internal to the kernel.

Any ideas? This is on the lspp.55 kernel.

Thanks,
Mike

Re: syscall record for mq_unlink

[Steve Grubb]

On Tuesday 21 November 2006 17:04, Michael C Thompson wrote:
> Any ideas? This is on the lspp.55 kernel.

Sounds like it might be a bug. Maybe one of the kernel people could look into 
it? If not, file a bug and we'll handle it that way.

Thanks,
-Steve

Re: syscall record for mq_unlink

[Michael C Thompson]

Steve Grubb wrote:
> On Tuesday 21 November 2006 17:04, Michael C Thompson wrote:
>> Any ideas? This is on the lspp.55 kernel.
> 
> Sounds like it might be a bug. Maybe one of the kernel people could look into
> it? If not, file a bug and we'll handle it that way.

I am seeing the same behaviour with mq_open... I'll file a bug so it 
doesn't get lost over the holidays, and I'll see if I can get some 
kernel people on my end to take a peek at it.

Thanks,
Mike