0

I have a simple script that runs fine under an app ID (just touches a new file), which I am trying to get to call via my personal ID. Note the target file location is in an area that my personal ID does not have write access to (but the owner of the script does) and I have set the SUID bit on the script, yet when i invoke it as my own ID (myID myGrp) , it gives permission denied on the touch.

The script's settings are correct as such:

-rwsrwxr-x appID appGrp 1.sh

(just contains touch /myDir/1)

This is the very purpose of the suid bit, yet it does not do what it's supposed to. Note the target dir has perms as follows:

drwxrwxr-x appID appGrp myDir

i do not want to turn that w ON for the dir. Defeats the purpose. Nor do I want to turn on the sticky bit on the dir.

As well i checked my mounts and ensured that the file system that dir resides on (in this case /app) has no NOSUID set, so it's clean also. was not mounted with nosuid.

How can i fix this?

Improve this question
6
  • 1
    Is this on a Linux system? See unix.stackexchange.com/q/364/117549
    – Jeff Schaller ♦
    May 27, 2020 at 1:06
  • oh sorry forgot to mention this particular one is on Linux 3.10.0, But I will be doing the same thing on AIX next as well and hoping i will not hit the same wall.
    – Steve237
    May 27, 2020 at 1:07
  • I read that link. Damn, so looks like Linux "ignores" that bit. Wth. then why does it exist. we need to patch the kernel. Woh, this is a corp server, I cannot approach anyone to do that. Also seems like this issue is only with scripts and not binaries? Hmmm....
    – Steve237
    May 27, 2020 at 1:12
  • Unless: I make a geneic C code to act like a wrapper to any shell script. It will take in the shell path and name as a parameter and fire it off. Then can it have the suid bit set and do the trick? If that's the case, it should work? ...
    – Steve237
    May 27, 2020 at 1:14
  • ok the easiest fix is to just add the personal ID to the same group (in /etc/group) as the dir's group, in this case to appGrp. This will just resolve the issue! But then I have to remove the group's W flag so users cannot modify the file(s) like -rwxr-xr-x appID appGrp 1.sh, so now if i am in appGrp group I can just run that script. And the final dir destination has: drwxrwxr-x appID appGrp myDir, so 1.sh can write there (me as part of that group that is). So the only mod is to remove all the W flags from all the scripts for group, as i don;t want ppl in the group modifying scripts.
    – Steve237
    May 27, 2020 at 1:43

1 Answer 1

Reset to default
-1

This was a feature that was quite useful back in the day. At some point, some folks started abusing it and they started disabling it in some flavors of UNIX. We didn't have sudo back then, so a lot of things that people might do with sudo were done with a script file that had the setuid bit set.

Allow setuid on shell scripts

Improve this answer
3
  • Yeah gocha! Thx
    – Steve237
    May 27, 2020 at 4:28
  • Interesting that people give me down votes for this answer. I guess it's a case of shoot the bearer of the bad news.
    – Grumpy OldMan
    May 27, 2020 at 16:29
  • while I haven't voted on this answer yet, I would point out that it doesn't answer the question "how do I fix this?". You've recently added a link to another post; your answer should stand on its own, whether you include the information in your own words, or quote the answer with attribution. The point is moot since the link refers to the same page that the duplicate points to; in those situations, the right thing is to simply vote to close this Q as a duplicate of the other -- not to write an answer. Thanks!
    – Jeff Schaller ♦
    May 27, 2020 at 17:19

Not the answer you're looking for? Browse other questions tagged .