Shell Programming and Scripting

Try which sudo...

--ahamed

@jlliagre
Post #6 is really scary. Korn Shell is supposed to ignore SUID and SGID bits on execution. You didn't set the SGID bit, so unless account "jlliagre" is also in group "other" it is hard to explain the output from "id".
What were the permissions on the directory containing the test script?

@machomaddy (Original Poster)
Are you 100% sure that you are running ksh? DRDOS/MSDOS style file extensions like ".ksh" have no meaning in unix or Linux. Is there a shebang line in the script?
What are the permissions of the directory containing the script?

@jima_mcnamara
"suid works for shell scripts"
By the book SUID and SGID on a script file should have no effect whatsoever on the execution of the script contents, but I have taken note of jlliagre's test.

My view:
My normal approach to this problem is to create a SUID,SGID wrapper program written in the "C" language and make it executable only by members of a specific unix group. This does not stop the executor reading the contents of the script so we have to hide passwords etc. in files owned by root. It's not perfect.

Bottom line:
Anybody know a definitive multi-platform solution to the problem of making a script file executable by a non-root user and also making the contents of the script invisible to that user?
Converting scripts to executable code may be the solution but I have yet to find a cross-platform script compiler.

It is not. The operating system (through the exec family system calls) is the component responsible to grant or not the suid bit to scripts.
ksh does certainly support suid scripts as it takes several specific measures to avoid exploits.
The sgid bit is not set so "guest" is keeping its group while running script.ksh. Nothing wrong or hard to explain here. They are "drwxr-xr-x 2 jlliagre jlliagre ...". By the way, jlliagre isn't in the "other" group but in the jlliagre group, as you might have guessed by reading the script group owner.
What book are you referring to ?

You might be interested to read this excellent post https://www.unix.com/302112883-post3.html , especially the chapter starting with: The Return of Suid Scripts

Thank you jlliagre for this most useful post. Not sure how your link is relevant, but it was interesting.

Obvously "by the book" is referring to documented rules. I can do without inane and condescending responses to serious subjects.

The fundamental rule that you cannot elevate the permissions of the contents of a script by changing the permissions of that script file appears to be incorrect in your O/S. I shall explore more. Admittely it was true in some implementations of early unix, but it should not occur in a modern unix.

If the account "jlliagre" is not in the SECONDARY group "other" then your post is still hard to understand. I am sure you know an account can be in more than one group.

Ps. Don't take this personally. The subject of elevating permissions of Shell Scripts is sensitive to me. I have yet to see a modern example, but yours may well prove to be the first.

@jlliagre. Please tell us which specific OS and version of ksh your example works on.

By default on Linux, setuid shell scripts are not supported. Such bits are ignored.

I'm afraid I don't understand your comment about the link not being relevant. It precisely states ksh is taking specific measures against exploits when called as a suid script and it explains how modern OSes, like Solaris, prevent other exploits to success.
That was my question. Do you have a link or something pointing to a place where these rules are documented ?
I stand corrected here. You certainly were expecting id to display the user's groups but the default Solaris id command doesn't do it. If I replace id with /usr/gnu/bin/id, guest is indeed member of both his original group and jlliagre's one.
I believe (but am not 100% sure yet) my example doesn't elevate the script permissions, it switches them from those of an unprivileged user to another unprivileged user. However, I probably should do more checking to be sure fine grained privileges granted to jlliagre's account do not interfere with my sample results.

---------- Post updated at 01:25 ---------- Previous update was at 00:40 ----------

My example was on "Oracle Solaris 11 Express snv_146 X86".
It works the same way on OpenIndiana build 151a, Solaris 10 and probably all previous SVR4.0 based Solaris releases.
I just tried on Solaris 11 FCS and the behavior is slightly different and actually better.
The suid bit still allows for an unreadable script to be executable but the euid is not changed anymore.
I don't think ksh version matters but I'm using what /bin/ksh refers to, i.e. ksh88 on Solaris 10 and likely ksh93t+ on all the SunOS 5.11 based OSes.
Indeed. I commented about what I know/read about OSes supporting or not suid scripts in post #12 https://www.unix.com/302592028-post12.html

@jlliagre
One place you can find reference to setuid and setgid being ignored is in "man ksh" in the section "Invoking ksh". Sounds like yours must be different.
There's a similar reference in Posix Shell manuals in the section "Shell Invocation".

More research has highlighted Solaris as a notable exception in the modern unix world. I'm pretty sure that suid scripts didn't work in SunOS 4.
It has been a problem to me in the distant past both when suid scripts did work and then when it suddenly stopped working!

Both "ksh" and the Posix Shell have a "-p" parameter. Indirectly the documentation for this switch explains the change of effective UID in your example.

With a bit of trial-and-error I managed to reproduce your test on HP-UX 11.1. The hint came from Sven Mascheck's site (below). On my tests it only works when there is a shebang line in the script.
With the original script owner as root and the permissions 4711 and while running as a non-priviliged user I used such a script to change a binary to permissions 6777 ! Scary.
Thankfully the passwd command doesn't work in a suid script (I already knew that). I've also checked that a non-privileged chown removes the suid bit.

This page from Sven Mascheck's excellent site has some decent lists and tables of O/S which allow suid scripts. The list omits a test result for HP-UX.
The #! magic, details about the shebang/hash-bang mechanism


This thread reinforces the old advice to not allow suid scripts and rubbishes the modern teaching and documentation that suid scripts don't work.