[lkml]   [1999]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: using capabilities to allow debug of suid-root programs (ptrace not allowed even after dropping privs) wrote:
    > [pjoot@openfire cap]$ ./debugwrap touch /blah
    > [pjoot@openfire cap]$ ls -l /blah
    > -rw-r--r-- 1 root build 0 Apr 17 13:24 /blah
    > [pjoot@openfire cap]$ ./debugwrap rm /blah
    > [pjoot@openfire cap]$ ls -l /blah
    > ls: /blah: No such file or directory
    > This seems no different then a plain old suid root program. I tried
    > setreuid(getuid(), getuid()) before the exec (and after the cap_set_proc),
    > but this clears other capabilities at the same time. I thought that the
    > whole idea of this capability stuff is so that the entire set of root
    > capabilities isn't explicitly inherited, but this appears to be what is
    > happening? Is the problem that ext2, or some other part of the kernel is
    > just not respecting the capabilities flags properly, and is unconditionally
    > doing the open which creates the file /blah when it sees the uid is 0?

    Remember, capabilities are only available (by default) for root to make
    use of. But root has a real account, so a setuid-root program can
    legitimately manipulate root-owned files even without any capabilities.
    Example, try this:

    [pjoot@openfire cap]$ touch /blah
    [pjoot@openfire cap]$ ls -l /blah
    -rw-r--r-- 1 pjoot build 0 Apr 17 13:24 /blah
    [pjoot@openfire cap]$ ./debugwrap rm /blah

    Unless root happens to own the cap directory, I believe you'll have some
    trouble deleting the file.



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.023 / U:1.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site