Hi,
How to restrict access to a .ksh script in such the way that the users can only execute the script, neither read nor write.
I tried the below code so that my user alone has the rwx and other users can only execute.
chmod 711 sample.ksh
But when I logged in as a different user and tried to execute the script, I get an error "Permission Denied".
How should I give the rights to the script to achive what I want?
What you want is not possible using permissions. To execute a script users need both r and x rights.. To take away only w rights, use chmod 755.
I don't think without read permission, execution is possible. Have you looked into sudoers?
--ahamed
Yes, without read it is not possible. Is there any workaround for this?
Like ahamed101 suggests you can use sudo definitions, so that users are denied access, but are given permission to execute the script as a different functional user if they belong to a certain group ...
Actually, it is possible to have a non readable script to be executable. This is done by setting the setuid bit on the script file. The script should not be owned by root for obvious security reasons.
$ cat script.ksh
#!/bin/ksh
echo this is $0
id
$ chmod 04711 script.ksh
Then, logged in as a different user:
$ id
uid=102(guest) gid=1(other)
$ cat script.ksh
cat: script.ksh: cannot open [Permission denied]
$ ls -l script.ksh
-rws--x--x 1 jlliagre jlliagre 30 Jan 22 14:46 script.ksh
$ ./script.ksh
this is script.ksh
uid=102(guest) gid=1(other) euid=12345 (jlliagre)
As you can see, the script will run under its owner account as effective user id, not the user who launches it . This might be a problem.
Another option (maybe not acceptable )is to render the the shell script unreadable by making it an executable image (with encrypted strings). Since you apparently have passwords or other very sensitive information in the shell scripts this is possibly a better idea.
Francisco Rosales, home page generic version, you have to edit the makefile for your OS
I tried jilliagre's method of setting the setuid bit. Still other users cant execute the script. Permission Denied.
suid works only for binaries is what I think...
--ahamed
---------- Post updated at 09:01 AM ---------- Previous update was at 09:00 AM ----------
What about sudoers or shc? Did you give it a try?
--ahamed
shc is not available in my system. I am working in client's system. Also, I am not aware of sudoers...Can you please throw more light on that?
ahamed -
suid works for shell scripts - it's an old idea. setuid works during the call to exec and as long as the file in question is executable with some other things like LD_PRELOAD taken into consideration. Some old systems will not run setuid with certain environment variables set, or those variable are ignored (more modern). That may be your problem.
What OS and ksh release are you using ?
Linux doesn't support suid scripts.
OSes that do support them are Solaris, Irix, UnixWare, and BSD based OSes with a kernel option set, NetBSD, OpenBSD and MacOS X.
I don't know about HP-UX and AIX.
look for the /etc/sudoers file. If it is there it tells you sudo is installed, probably someplace like /usr/local/bin, which may not be in your PATH.
I couldn't find sudoers file in my system. Also, am using Linux 2.6.18
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 The Whole Story on #! /usr/bin/ksh Post: 302112883 , 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 Restrict access to .ksh scripts Post: 302592028