When you run a php script in the command line, does is execute with the read/write permissions of the current user or what?
Yes, it does.
Yes, it runs with the permissions of the current user. Just like executing any other command-line program.
Yes, it will run as the current user in a default setup.
If you where on a unix system you could change this by adjusting the setuid bit of the php cli binary. Of course doing so would be a bad idea.
Related
I am wondering when and why do we need execution permission in linux although we can run any script without execute permission when we execute that script using the syntax bellow?
bash SomeScriptFile
Not all programs are scripts — bash for example isn't. So you need execute permission for executable programs.
Also, when you say bash SomeScriptFile, the script has to be in the current directory. If you have the script executable and in a directory on your PATH (e.g. $HOME/bin), then you can run the script without the unnecessary circumlocution of bash $HOME/bin/SomeScriptFile (or bash ~/bin/SomeScriptFile); you can simply run SomeScriptFile. This economy is worth having.
Execute permission on a directory is somewhat different, of course, but also important. It permits the 'class of user' (owner, group, others) to access files in the directory, subject to per-file permissions also allowing that.
Executing the script by invoking it directly and running the script through bash are two very different things.
When you run bash ~/bin/SomeScriptFile you are really just executing bash -- a command interpreter. bash in turns load the scripts and runs it.
When you run ~/bin/SomeSCriptFile directly, the system is able to tell this file is a script file and finds the interpreter to run it. There is a big of magic invoking the #! on the first line to look for the right interpreter.
The reason we run scripts directly is that the user (and system) couldn't know or care of the command we are running is a script or a compiled executable.
For instance, if I write a nifty shell script called fixAllIlls and later I decide to re-write it in C, as long a I keep the same interface, the users don't have to do anything different.
To them, it is just a program to run.
edit
The operating system checks permissions first for several reasons:
Checking permissions is faster
In the days of old, you could have SUID scripts, so one needed to check the permission bits.
As a result, it was possible to run scripts that you could not actually read the contents of. (That is still true of binaries.)
I need a Shell script, this shell script should :
1. create another shell script
2. set the suid bit for new script as a root user
3. run this new script as current user
Can we do this?
anyone can give any idea or some code snippets?
This will not work under many versions of unix (or linux). The setuid bit on shell scripts is typically ignored, since it is far too easy to subvert such a program.
I created a script which I want other users on our shared system to execute but not read. I set the permissions as executable for all but revoked the R/W rights.
---x--x--x 1 dilletante staff 0 2013-04-02 11:42 expect.sh
However the script Fails to execute...The reason is simple.. The interpreter also needs to read the script
I want a workaround if any..Can I embed it into some compiled language..Would that work?
If yes, could you point to the resources where I can learn how to do so..
The shell has to be able to read a script to execute it. You are asking for the impossible if it is a script.
You can certainly use 111 permission on an executable program (as produced by the ld command, typically invoked by the compiler of your chosen compiled implementation language). The owner can always change the permission to read the program if they want to, but it is more conventional to use 511 than 111 permission.
There are often compilers for a specific script language that will generate a C program equivalent to the script:
Compilers for shell scripts.
How to compile a Linux shell script as a binary.
Compiling shell scripts.
shc — shell script compiler.
Etc.
If you want this for other users try sudo
Example:
Change execution right
chmod 500 /usr/bin/script.bash
ll /usr/bin/script.bash
-r-x------ 1 <USER> <GROUP> 1174 23. Jan 13:24 /usr/bin/script.bash
As root change sudoers
visudo
## Allows ALL to run /usr/bin/script.bash as <USER> without password
## The asterisk is if you want to use any commandline parameters
ALL ALL=(<USER>) NOPASSWD: /usr/bin/script.bash *
Run script with sudo
sudo /usr/bin/script.bash <PARAMETERS>
For further information concerning sudo read the sudo manpages
There's an alternative to securing your shell scripts. Since the goal here is to make sure no one can read or alter them, you may want to give the following link a try:
http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm
On the above page, all you have to do is submit your shell script (you can submit a sample script first for your peace of mind). A zip file will be generated for you.
Installation:
wget link-to-the-zip-file
unzip the-newly-downloaded-zip-file
cd /tmp/KingLazySHIELD
./install.sh /var/tmp/KINGLAZY/SHIELDX-(name-of-your-script) /bin -force
What the above install command will do for you is:
It'll install the encrypted script in the directory /var/tmp/KINGLAZY/SHIELDX-(name-of-your-script).
It'll place a link to this encrypted script in /bin - that way, you need not type the absolute path to your script each time you want to run it.
Ensures NO ONE can modify the script - Any attempts to modify the encrypted script will render it inoperable...until the attempts are removed.
Ensures absolutely NO ONE can make working copies of it. No one can copy your script to a secluded location and try to screw around with it to see how it works. If they try to, it'll abort and will not run.
I made my own bash obfuscator to overcome some shortcomings of shc which really bugged me (the primary one as being able to see the script in almost clear text with the use of ps).
You could have a look if https://github.com/louigi600/obash serves you any better then shc.
I try to create my own linux bash script that calls truecrypt for mounting. As option a need to set the password for the truecrypt file. I can do this inside the bash script but if someone open it, they can see the password. The script will later run automatically.
My question: Is there some safe way to hide/encrypt the password?
Example:
truecrypt --mount --password="testing" /home/username/test.tc /home/username/mount/
Thanks for any help!
Use SHC. It encrypts shell scripts using RC4 and makes an executable binary out of the shell script which you can run.
Download SHC(http://www.datsi.fi.upm.es/~frosal/) and install it.
Create a shell script with in "truecrypt --mount --password="testing" /home/username/test.tc /home/username/mount/" andsave it as "yourfilename.sh".
Now, run the command :
shc -f yourfilename.sh
The switch "-f" specifies the source script to encrypt. The above command will create two files: yourfilename.sh.x.c and yourfilename.sh.x.
The program "shc" creates C source code out of your shell script then encrypts it (yourfilename.sh.x.c). The encrypted shell script is: yourfilename.sh.x. Run that binary and it executes your commands:
./script.sh.x
There is no safe way to store the password without someone being able to read it. The only options you have are to use user rights to limit who can see it. You can make the script readable only to the user who's password is in it as one options. Another is to have the script read the password from a file which has a similar permission set (this just gives you more flexibility with updating the script and such).
Ultimately though any admin/superuser can read the file anyways so this isn't something you can do safely. The thing most people suggest is to have the script run automatically and present a GUI for the user to input their password. These vary based on your distribution but they are usually there.
I decided to learn C++ (I program in C at work), and I have been reading some tutorials (and lots of posts here on Stack Overflow). OK, so I typed in the standard C++ "hello word", compiled with GCC on my Ubuntu machine as "test".
Then I tried to run it by typing "test" and hitting enter. Nothing. It turns out I must run it with "./test". OK, fine, I'll do that from now on. But why? The "./" just says that what I should run is in the current directory... Is the current directory not always part of the PATH when the OS is searching for something to run? Can I make it so?
Yes, the current directory is not part of your PATH. You don't want it to be, because then you could be in a directory that had a malicious program you didn't know about that you run.
What if you were used to running /usr/bin/grep, but you happened to be in a directory that a Bad Person put a malicious copy of grep in, and this time you run grep, and you're running grep out of the current directory, rather than /usr/bin/grep.
You certainly can add ./ to your PATH in your ~/.profile or ~/.bash_profile, but I don't recommend it.
And if it makes you feel any better, I had the same frustration 15 years ago when I started using Unix-like systems.
You can add "." to your PATH, but that won't help you in this case - "test" is a shell built in.
Unfortunately, there is a Unix command called "test"...
If there's a command line script you regularly run, you could set up a command line alias to rid yourself of the need to type ./ each time.
Even if the current directory is at the very beginning of the $PATH, 'test' still won't run it on (most?) shells, as 'test' is a shell built-in command.
Not having '.' (the current directory) in the PATH is a minor security measure. You could always add it in if you'd like, though it's not a best practice.
In case it's not clear, this is an aspect where Windows differs from Unix/Linux. On Windows, the current directory is implicitly in the path.