LinuxQuestions.org - [SOLVED] setting group ID for executable file working under Solaris but not under Linux

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - setting group ID for executable file working under Solaris but not under Linux (https://www.linuxquestions.org/questions/linux-software-2/setting-group-id-for-executable-file-working-under-solaris-but-not-under-linux-819742/)

setting group ID for executable file working under Solaris but not under Linux

Hello,

Does anyone have any idea regarding what could be the problem here, i.e. why do I get "Permission denied"?

Code:

[andreas@loony /tmp]$ ls -al

total 40

drwxrwxrwt  4 root root  4096 Jul 14 10:28 .

drwxr-xr-x 28 root root  4096 May 18 10:55 ..

-rw-r--r--  1 root root  1696 Dec 17  2009 bar

drwxrwxrwt  2 root root  4096 May 18 10:55 .font-unix

drwxrwxrwt  2 root root  4096 May 18 10:55 .ICE-unix

-rwxr-sr-x  1 root tripdb  27 Jul 14 10:26 sas.sh

-rw-r-----  1 root tripdb  26 Jul 14 10:27 textfil.txt

[andreas@loony /tmp]$ ./sas.sh

cat: textfil.txt: Permission denied

[andreas@loony /tmp]$ cat sas.sh

#!/bin/sh



cat textfil.txt

[andreas@loony /tmp]$

Since the s-bit is set for the group for sas.sh, it should run with the permissions of the group tripdb, which has read rights to textfil.txt. However, it does not work on any of our Linux systems that I have tried it on. We also have one machine running Sun Solaris, and there exactly the same thing works.

SELinux is disabled, so that is not the problem.

It is RHEL and CentOS that I have tried it on.

Edit:
A colleague told me that this does not work for shell scripts (even though apparently it does work for shell scripts under Solaris). However, this is not the problem per se, because I discovered this problem when using a binary program that needs the s-bit feature. I only made the small shell script to make sure that I understand everything that is going on and that it is not the binary program that is behaving badly... but I do believe that the problem is not in the program but in the operating system.

Edit:
Set uid works. It is only set gid that does not work. That is, setting the s-bit for the owner works, but setting the s-bit for the group does not.

You must have made a mistake with your program, the behaviour will succeed with a binary and fail with a script as it was designed to. SUID and SGID bits are ignored on scripts as allowing it would be a security risk.

eg.

Code:

# cp /bin/cat /tmp

# chmod g+s /tmp/cat

# ls -l /tmp/cat

-rwxr-sr-x. 1 root root 48292 2010-07-14 23:05 cat

# ls -l /tmp/test.txt

-rw-r-----. 1 root root 8 2010-07-14 23:06 /tmp/test.txt

$ /tmp/cat /tmp/test.txt

some garbage

$

cheers

This question reminded me of a product made by Cactus Software long ago that converted shell scripts into binaries.

On looking to see if there was any GNU stuff that does that now I found several references to shc. I haven't used it myself (yet) but you might want to look into it for your testing:
http://www.datsi.fi.upm.es/~frosal/

Note: If it works like the other software I saw it isn't really converting anything - its just running the commands from within the binary so it isn't any faster than the shell script it is based on. The average binary is normally than a shell script so just thought I point out this may not be the case for an shc binary.

Thank you for the tips.

kbp is right. I tested it with cat as he suggested, and that works.

It is not my program and I do not even have the source code. I will probably have to contact the makers of the program.

My point was that you can make the shell script into a binary and test it using shc. There is no "source" for a script - it is all in the script. If you already have a binary you don't need the source to do the sgid or suid as show by the cat test you did.

Quote:

Originally Posted by MensaWater (Post 4035246)

Yes, I understood that, thank you. It is the third party binary program that I do not have the source code do. Therefore, I was unable to check why setting the s-bit worked with cat but not with the program I needed it to work with. For some reason, the solution was to add x-permission for "other" to the directories containing the files that the program needed to open. The files themselves do not need any permissions for "other", but the directories must have x-permission for "other".