Shell Programming and Scripting

Hi,

I have the following 3 test files to test setuid bit which if it works I would like to implement in our application. However setuid doesnot seem to be having any impact on my test below.Following are the 3 files of interest in /tmp/ folder.

Code:

[usl20010097 tmp]$ ls -ltr *env*
-rw------- 1 g332008 users 6 Jun 25 17:31 mainoutputfile.txt
-rwxr-x--x 1 cddsuat cddsuat 38 Jun 25 17:51 subscript.ksh
-rwsr-xr-x 1 g332008 users 51 Jun 25 17:53 mainscript.ksh

As you can see /tmp/subscript.ksh
is owned by user cddsuat. It invokes /tmp/mainscript.ksh
and has the following contents:

Code:

-bash-3.2$ cat subscript.ksh
#!/usr/bin/ksh
/tmp/mainscript.ksh

/tmp/mainscript.ksh has the following contents:
[usl20010097 tmp]$ cat mainscript.ksh
#!/usr/bin/ksh
echo "hello" >> /tmp/mainoutputfile.txt

Based on the above, setuid bit has been set for owner on /tmp/mainscript.ksh. This means that when /tmp/subscript.ksh invokes /tmp/mainscript.ksh, /tmp/mainscript.ksh runs as the owner of /tmp/mainscript.ksh which is g332008 rather than user cddsuat. So /tmp/mainscript.ksh should be able to write "hello" to the file /tmp/mainoutputfile.txt which is owned by g332008. However when I run /tmp/subscript.ksh I get the following error with respect to write permission on /tmp/mainoutputfile.txt.

-

Code:

bash-3.2$ ./subscript.ksh
/tmp/mainscript.ksh[2]: /tmp/mainoutputfile.txt: cannot create [Permission denied]

Please advise why do I get the above permission error even though /tmp/mainscript.ksh has setuid bit set so that any other user invoking this script would be able to run this script as the owner of /tmp/mainscript.ksh. Your advise is much appreciated.

thanks

1. most ksh insist in safe mode

Code:

#!/usr/bin/ksh -p

2. Linux does not support suid scripts. You need to write and compile a binary helper, or use an existing helper like sudo.

I didnot know that setuid is not supported by Linux.
But I noticed that the /usr/bin/passwd binary has setuid set on Linux. Similarly ping program also has setuid bit set on Linux.
How is that possible if Linux doesnot support setuid. ALso how will the passwd command write to /etc/shadow if setuid is not supported on Linux. Also how come I saw the rwsr-xr-x permission on the /usr/bin/passwd executable ?
Please throw some light.

thanks

---------- Post updated at 12:48 AM ---------- Previous update was at 12:36 AM ----------

My objective is for an environment file which has database passwords in it NOT to be readable by the anybody logging as the application user but at the same time the script which uses these passwords must be able to execute some script and read these passwords and use the passwords for running its internal database sqls'. I was thinking of making the environment file owner as root with no read permission to the application userid so that nobody can view the passwords and then use setuid bit on the support script which when called by the main script is able to fetch these passwords as it runs as root user. But since setuid is not supported by Linux I will not be able to make the password file non-readable owned by root and be able to execute some setuid script that can fetch the passwords from this root owned password file.
Any suggestions on an alternative way to achieve this would be highly welcome ?

thanks

your example setuid files are binaries and not scripts btw ...


as for your issue ... (not advisable but an option nonetheless) ...

1. create generic database admin user like "sqadmin"
2. set sqadmin $HOME permissions to 700
3. write sqluser password into sqadmin's $HOME/.sqlpass
4. chmod 500 $HOME/.sqlpass
5. run crypt on $HOME/.sqlpass
6. in sqadmin's script, uncrypt $HOME/.sqlpass to read password and then recrypt
7. continue processing of sqadmin script

It'd be better to use sudo for this... Allow users to run said script and only said script as another user. (Does NOT need to be root. More secure if it is not, in case someone exploits a bug in your script.)

Yes it does, but you have to consider the filesystem it is in though. Many installations only allow SUID scripts in OS filesystems (/, /bin, /sbin, /usr/bin depending how you have them mounted) and as such you may find that /home (or wherever) is mounted with that disabled.

Change to the directory where the script is and do the following:-

Code:

df -k .
grep "filesystem name" /etc/fstab

Remember to escape the forward slash in the grep command, e.g.

Code:

grep "\/my\/filesystem" /etc/fstab

What do you have in the fourth column? Actually, post the whole line.



Robin
Liverpool/Blackburn
UK

Your analysis of the situation is incorrect, rbatte.

While you are correct that mount options can forbid suid binary executables (and even non-suid executables), linux does not support suid interpreted script executables, regardless of mount options.

Regards,
Alister

---------- Post updated at 02:06 PM ---------- Previous update was at 12:04 PM ----------

In case anyone is interested, a more detailed explanation.

Relevant functions from the 3.9.7 stable kernel:
fs/exec.c :: do_execve_common()
fs/exec.c :: prepare_binprm()
fs/exec.c :: search_binary_handler()
fs/binfmt_script.c :: load_script()

Linux can support many executable formats. Each format has a dedicated handler registered with the kernel. When loading an executable, the execve syscall must first identify the format of the executable. This is accomplished in search_binary_handler by walking the list of registered handlers until one of them succeeds. If none succeed, the system call fails.

This procedure can occur more than once. A typical, successful shell script execve requires two passes. The first pass ends with the success of load_script, the handler that recognizes the #! shebang header. This handler parses the interpreter's pathname from the shebang line and uses it to begin the second pass. Usually, the interpreter is a native binary (e.g. sh, awk, perl, etc), in which case this second handler search concludes with load_elf_binary.

The kernel calls prepare_binprm before each pass.

prepare_binprm resets the effective uid and gid to match that of the current process (execve's caller), before checking the inode of the executable it intends to load. If the inode's mode has a SUID/SGID bit set, then the euid/egid for the to-be-loaded executable is set to match the inode uid/gid (incidentally, rbatte, this is also where the NOSUID mount option check is located).

The first prepare_binprm call is in do_execve_common and involves the SUID shell script executable. The second call is in load_script and involves the interpreter pathname.

Between the two calls to prepare_binprm, the relevant data structure actually has the shell script owner's credentials, as if the kernel intends to allow the change in ownership. However, the second prepare_binprm invocation (just as the first) resets the euid/egid values to those of the current process. The shell script's inode's SUID/SGID change is clobbered and this time prepare_binprm consults the interpreter's inode, not the shell script's.

Regards,
Alister