Bug 233220 - LSPP: readlink readlinkat missing obj context
LSPP: readlink readlinkat missing obj context
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Martin Jenner
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
Reported: 2007-03-20 20:41 EDT by Debora Velarde
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-22 12:25:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Debora Velarde 2007-03-20 20:41:11 EDT
Description of problem:
No obj context appears in the audit record when the readlink or readlinkat
syscall fails.  

Version-Release number of selected component (if applicable):

How reproducible:
Always on multiple platforms.

Steps to Reproduce:
1. mkdir /root/tmp
2. chmod 700 /root/tmp
3. echo "blah" > /root/tmp/test_file
4. ln -s /root/tmp/test_file /root/tmp/test_file_symlink
5. Create and compile test program that contains the following:
        int rc=0, buf_size=30;
        char buf[30];
        char *arg0 = "/root/tmp/test_file_symlink";

        /* Run the test */
        rc = readlink( arg0, buf, buf_size);

6.  Add the following audit rule:
        auditctl -a exit,always -S readlink

7.  Run the test program as a non-root user.

Actual results:
Resulting audit records are as follows (notice PATH record contains a name but
no obj context)

type=SYSCALL msg=audit(1174434067.359:1007): arch=14 syscall=85 success=no
exit=-13 a0=100008b0 a1=ff4df854 a2=1e a3=ff4dfb70 items=1 ppid=5797 pid=5847
auid=500 uid=502 gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502
tty=pts3 comm="bug_readlink_te" exe="/tmp/bug/bug_readlink_test"
subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null)

type=CWD msg=audit(1174434067.359:1007):  cwd="/tmp/bug"

type=PATH msg=audit(1174434067.359:1007): item=0 name="/root/tmp/test_file_symlink"

Expected results:
Should contain an 'obj' context like there is in the successful case, when the
user does have valid permissions.
type=SYSCALL msg=audit(1174434139.977:1008): arch=14 syscall=85 success=yes
exit=19 a0=100008b0 a1=fa7bf654 a2=1e a3=fa7bf9b4 items=1 ppid=4212 pid=5849
auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2
comm="bug_readlink_te" exe="/tmp/bug/bug_readlink_test"
subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)

type=CWD msg=audit(1174434139.977:1008):  cwd="/tmp/bug"

type=PATH msg=audit(1174434139.977:1008): item=0
name="/root/tmp/test_file_symlink" inode=2031637 dev=fd:00 mode=0120777 ouid=0
ogid=0 rdev=00:00 obj=staff_u:object_r:sysadm_home_t:s0

Additional info:
Comment 1 Eric Paris 2007-03-21 16:09:22 EDT
Adding amy to see if she has input.

Looks like audit_inode inside fs/namei.c:do_path_lookup is conditionalized on
retval = 0;  I'm assuming link_path_walk is giving us a permission error.  The
'old' obj that was logged was just leftover crap fixed in 223918

If we never actually drill down and find the inode we don't know what the obj is
to be able to log it.  Remember the failure is not always that we can't read the
actual file /root/tmp/test_file_symlink but in this case we can't even get into
/root and so we don't know the label on the actual symlink.  I'm thinking
Comment 2 Amy Griffis 2007-03-22 11:57:08 EDT
That's right, if you couldn't traverse the directory tree to the object, audit
doesn't have to log the object info.

Other than that, I don't see a problem. For success I get:

type=PATH msg=audit(1174578545.504:660): item=0 name="sym-low" inode=721268
dev=ee:00 mode=0120777 ouid=0 ogid=0 rdev=00:00

and failure:

type=PATH msg=audit(1174578562.583:662): item=0 name="sym-high" inode=721267
dev=ee:00 mode=0120777 ouid=0 ogid=0 rdev=00:00

This is the info for the symlinks themselves, not the object they point to.
Comment 3 Debora Velarde 2007-03-22 12:01:24 EDT
OK, if we change the file from /root to a different directory things work as

OK to close.

Note You need to log in before you can comment on or make changes to this bug.