how do i run valgrind to a process which has super user bit on?

R

5

15

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

Remex answered 9/11, 2009 at 15:29 Comment(0)

T

4

This is a perpetual problem for people who develop FUSE file systems. This link may help (it's quite literally too much to consolidate in a single answer). The work-around involves a just-in-time replacement of fusermount, and (depending), some additional options to valgrind to prevent it from tracing children.

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 ....

The easiest thing to do is all of your debugging in a disposable VM running as root, where you can just ditch the setuid bit, and be done with it. Make sure you test your code to not have any leaks or violations, its easy enough to test any linked library code not using fuse. Hand your build off 'valgrind-clean' and note that you've done so in the documentation.

Then, grab some bits out of valgrind/valgrind.h to detect it, and show a short message for those that go ahead and run it anyway. Hacks to work around it require root cooperation, and quite frankly, are much easier done in a sandbox just as well.

It's also easy enough to refuse to run under valgrind with the setuid bit on, showing a helpful message for people to turn it off if they really want to do it.

Trembly answered 9/11, 2009 at 15:48 Comment(0)

S

4

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...

Situation answered 9/11, 2009 at 15:41 Comment(3)

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 :) – Trembly 9/11, 2009 at 15:56

True, as (almost) always there are exceptions, but generally this approach should do the trick. – Situation 9/11, 2009 at 16:4

just running valgrind as root didn't seem to be enough, but chown worked! :) – Hujsak 24/10, 2019 at 3:7

T

4

This is a perpetual problem for people who develop FUSE file systems. This link may help (it's quite literally too much to consolidate in a single answer). The work-around involves a just-in-time replacement of fusermount, and (depending), some additional options to valgrind to prevent it from tracing children.

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 ....

The easiest thing to do is all of your debugging in a disposable VM running as root, where you can just ditch the setuid bit, and be done with it. Make sure you test your code to not have any leaks or violations, its easy enough to test any linked library code not using fuse. Hand your build off 'valgrind-clean' and note that you've done so in the documentation.

Then, grab some bits out of valgrind/valgrind.h to detect it, and show a short message for those that go ahead and run it anyway. Hacks to work around it require root cooperation, and quite frankly, are much easier done in a sandbox just as well.

It's also easy enough to refuse to run under valgrind with the setuid bit on, showing a helpful message for people to turn it off if they really want to do it.

Trembly answered 9/11, 2009 at 15:48 Comment(0)

C

1

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

Crespi answered 9/11, 2009 at 15:40 Comment(2)

This link is now dead. – Icarus 27/5, 2019 at 13:58

The page can be found on the Wayback machine. web.archive.org/web/20100123225207/http://old.nabble.com/… – Wrung 6/12, 2020 at 14:24

D

-1

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.

Ditch answered 9/11, 2009 at 15:37 Comment(1)

Sometimes, that's just not possible :) – Trembly 12/11, 2009 at 17:7

T

-1

This happens even when things were run as root user :) Best way is to change the perms to remove "s", and run

Templet answered 6/6, 2014 at 11:40 Comment(1)

suid does not mean root. It means set user id where "user" can be anything. – Hysteresis 26/8, 2020 at 12:45

Recommended topics

Hot tags