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?

muru
  • 72,889
Steve237
  • 103
  • 1
    Is this on a Linux system? See https://unix.stackexchange.com/q/364/117549 – Jeff Schaller May 27 '20 at 01: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 '20 at 01: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 '20 at 01: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 '20 at 01: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 '20 at 01:43
  • Yes it's basically similar link to what Jeff sent above. Seems like I have to make a C code to wrap it with. Or I may just fiddle with the groups to get it working. Thx all! – Steve237 May 27 '20 at 04:26

1 Answers1

-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

Grumpy OldMan
  • 26
  • Yeah gocha! Thx – Steve237 May 27 '20 at 04: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 '20 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 '20 at 17:19