[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.053 / U:20.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site