1

This is related to this question.

I have a script (fix-permissions.sh) that fixes some file permissions:

#! /bin/bash 
sudo chown -R person:group /path/
sudo chmod -R g+rw /path/

And a small c program to run this, which is setuided:

#include "sys/types.h"
#include "unistd.h"
int main(){
    setuid(geteuid());
    return system("/path/fix-permissions.sh");
}

Directory:

-rwsr-xr-x  1 root  root  7228 Feb 19 17:33 fix-permissions
-rwx--x--x  1 root  root   112 Feb 19 13:38 fix-permissions.sh

If I do this, everything seems fine, and the permissions do get correctly fixed:

       james $ sudo su someone-else
someone-else $ ./fix-permissions

but if I use strace, I get:

someone-else $ strace ./fix-permissions
/bin/bash: /path/fix-permissions.sh: Permission denied

It's interesting to note that I get the same permission denied error with an identical setup (permissions, c program), but a different script, even when not using strace. Is this some kind of heureustic magic behaviour in setuid that I'm uncovering?

How should I figure out what's going on?

System is Ubuntu 10.04.2 LTS, Linux 2.6.32.26-kvm-i386-20101122 #1 SMP

Community
  • 1
James
  • 290

1 Answers1

5

Linux ignores the setuid bit when running a process under strace or similar programs.

  • Linux-Kernel mailing list, Re: 2.4.16 + strace 4.4 + setuid programs:

    From: Manfred Spraul
    Date: Thu Dec 06 2001 - 12:25:53 EST

    If you want to strace setuid things and have the setuid bit honored, you have to run strace as root with the -u option.

    No, even that's not possible anymore. setuid is now always ignored if a process is ptraced, even if root is ptracing - that's the fix for the latest ptrace root exploit (2.4.1x).

which is probably talking about:

grawity
  • 501,077