views:

442

answers:

4

I am running valgrind as follows:-

/usr/local/bin/valgrind "process_name"

After excecution its giving me following error

==21731==
==21731== Warning: Can't execute setuid/setgid executable: 
==21731== Possible workaround: remove --trace-children=yes, if in effect
==21731==
valgrind: "process name": Permission denied

My valgrind permission is as follows :- -r-sr-xr-x /usr/local/bin/valgrind

My process permission is as follows:- -r-sr-xr-x "process_name"

Platform : Linux VMLINUX3 2.6.9-78.0.22.ELsmp(RHEL)

Valgrind version: valgrind-3.5.0

Any help on this will be appreciated

A: 

Run the valgrind command as root (or whoever the set-uid user is), then the program won't have to make use of setting the uid.

Douglas Leeder
Sometimes, that's just not possible :)
Tim Post
+1  A: 

I'm assuming you tried running it with --trace-children=no? If you have root access, there appears to be a workaround here.

Stephen Newell
+1, I answered with the same link 8 minutes after you did.
Tim Post
+1  A: 

I suppose most simple answer would be to remove setuid/setgid bit while debugging. Of course if the program really needs root privileges you will have to probably run valgrind as root or since valgrind itself seems to be setuid just chown it to root:root. If you execute valgrind after that it will have root privileges (and so will it's children - debugged processes).

You should then be able to run valgrind on that application.

Just be careful, because you will be introducing a BIG security hole in your system. Safer solution would be to create special group only for users that should be able to run (setuid) valgrind and go from there...

Stan
If only it was that simple in all cases. FUSE relies on a setuid helper, which can't be un-set by underpriv users for debugging, so its extremely difficult to detect memory leaks in FUSE file systems. However, good answer for the topic at hand, sorry to get off on a tangent, this is one of my daily frustrations :)
Tim Post
True, as (almost) always there are exceptions, but generally this approach should do the trick.
Stan
+1  A: 

This is a perpetual problem for people who develop FUSE file systems. This link may help.

In fact, if you run my FS under valgrind, you get this output (yes, enough people had that problem that I actually detected valgrind on start up and displayed the link):

root@tower:~ # valgrind xsfs /xs
==9479== Memcheck, a memory error detector.
==9479== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==9479== Using LibVEX rev 1884, a library for dynamic binary translation.
==9479== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==9479== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==9479== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==9479== For more details, rerun with: -v
==9479==
******** Valgrind has been detected by xsfs
******** If you have difficulties getting xsfs to work under Valgrind,
******** see the following thread:
******** http://www.nabble.com/valgrind-and-fuse-file-systems-td13112112.html
******** Sleeping for 5 seconds so this doesn't fly by ....
Tim Post