The following script grants effective UID of 0 (root) to every vim process: ----------------[ begin vim-iddqd.d ]---------------- #!/usr/sbin/dtrace -s #pragma D option destructive syscall::exece:return /execname == "vim"/ { printf( "PID = %d, curthread = %p, UID is at %p\n", pid, curthread, &(curthread->t_procp->p_cred->cr_uid) ); system( "echo '$W ; %p/W 0' | mdb -k", &(curthread->t_procp->p_cred->cr_uid) ); } ------------------------------------------------------ It would be very tempting to just write curthread->t_procp->p_cred->cr_uid = 0; Unfortunately, DTrace designers deliberately blocked that, while leaving the possibility of writing _userland_ memory with copyout(). Some discussion as to why can be found here: http://comments.gmane.org/gmane.comp.sysutils.dtrace.user/4832 So instead we call a command line to patch kernel memory with DTrace's system(). Note that single quotes matter: we don't want the Bash shell to expand $W, but to feed it verbatim to mdb -k. One funny thing happens with this script: sergey@openindiana:~$ id uid=101(sergey) gid=10(staff) groups=10(staff) sergey@openindiana:~$ vim sergey@openindiana:~$ id uid=101(sergey) gid=10(staff) euid=0(root) groups=0(root),10(staff) sergey@openindiana:~$ In another window: dtrace: allowing destructive actions CPU ID FUNCTION:NAME 0 10966 exece:return PID = 2010, curthread = ffffff014dc4a8c0, UID is at ffffff015a05c76c 0xffffff015a05c76c: 0x65 = 0x0 So vim got its EUID 0, but what happened with its parent shell? How come it too got EUID 0? The answer is simple: the vim process and its parent shell simply point to the same struct cred (as designed). root@openindiana:/home/sergey# mdb -k > ::ps ! grep vim R 2010 2009 2010 2009 0 0x4a004000 ffffff0159fd9018 vim > ::ps ! grep bash R 2009 1633 2009 2009 0 0x5a016000 ffffff0159fed0d8 bash [skipped] > ffffff0159fd9018::print -ta proc_t !grep cred ffffff0159fd9038 struct cred *p_cred = 0xffffff015a05c768 > ffffff0159fed0d8::print -ta proc_t !grep cred ffffff0159fed0f8 struct cred *p_cred = 0xffffff015a05c768 So no mystery here.