i am using shell_exec to get whois details of a domain. Everything is working fine on localhost but when i am uploading the script on server, it is creating problems. On server, the shell_exec is working partially.
echo "shell_exec('whoami')";
gives me an output.
mac
but when i am using
echo "shell_exec('whois example.com')";
I am getting a blank page
Should i consider using a hosting account with root privilege? If yes then how to deal with security issues?
P.S- i dont know if something like this even exists but i've tested it on localhost and it is running fine on MAMP.
Thanks in advance.
If you do decide to host this script with root privileges, then you should (and I'm sorry) be locked up in a padded cell. That's just mad! You don't need root privileges to run a simple whois command. That's insane!
Hosting as root is about as safe as a nursery, ran by catholic priests, serial killers and crack addicts, who haven't had a fix in three days. Things are going to happen... You can only speculate as to when and how bad it's going to end.
Check using whoami what user is running the script, then check what it's PATH looks like, compare that to where whois actually is, if at all present. If it's not installed, ask your admin to set it up, and give you the rights to use it. If it's installed, try shel_exec('/path/to/bin/whois example.com');
Read up on user rights, and environment variables, (and how to load/manipulate them from a PHP script)
Related
We have a small office intranet, built in PHP (on an apache server - so WAMP), that allows us to create project folders on our file server. This works by copying a set of template folders to a new location using the shell exec xcopy command and the following switches /e /k /i /c.
We (fairly) recently upgraded to a new file server running Windows Server 2008 R2 Standard. Now the xcopy command no longer works from within PHP. However, I know that the xcopy command is correct because it works if I copy and paste it into a command prompt (on the same machine).
I can see no error message but I assume this is some kind of permissions issue related to the PHP 'user', but I don't know exactly what or how to solve it.
The apache server and the file server are two separate machines. If it's relevant, the apache server is a 32bit machine and the file server is a 64bit machine but, as I say, I can invoke the xcopy command from the CLI of the 32bit machine without a problem.
The Apache process user name is SYSTEM (although I can't seem to use the 'whoami' command to check this)
Any pointers would be greatly appreciated.
FWIW, the exec string looks like this...
echo "xcopy \"\\\\path\\to\\folder\\xxxx_Project\\*.*\" \"\\\\path\\to\\folder\\9876_NEWPROJECT\" /e /k /i /c";
which (I think) materializes as this...
xcopy "\\path\to\folder\xxxx_Project\*.*" "\\path\to\folder\9876_NEWPROJECT" /e /k /i /c
Obviously, the '9876_NEWPROJECT bit is really a variable.
OK. I seem to have got it working. Here's what I did - tell me if it's a bad idea although I should point out that this is an intranet so I'm a little less concerned about security...
Go to Control Panel->Administrative Tools_>Services
Select the Apache service and hit Properties
On the Log On tab, click 'This account:' instead of 'Local System account', and then find the User account of Windows user who's normally logged on to that terminal
Restart Apache
I also amended the user info in the httpd.conf file, but I'm not actually certain that that was necessary.
If there's a better solution, that can be explained in words of two syllables or less, I'm all ears!
get_current_user() will confirm the user your script runs as.
Then try to manually execute your command as this user with runas (or if your user really is SYSTEM then you will need something like psexec to do so).
Now, assuming that your script actually runs as SYSTEM, it is very likely that this user is not authorised on the remote file server. I don't think it is even possible to do that (except, perhaps, by allowing "Everyone"). If it is, I am not sure this is a good idea anyways.
I would instead run the apache service as a regular user, and on the file server, grant access to this user.
Alternatively, you could mount the remote location as a network drive (not tested, other answers in the thread might help too).
I have a server A where some logs are saved, and another server B with a web server (IIS) on it.
I can access serverA from Windows Explorer with zero problems, but when I want to access it from serverB with some PHP code, it doesn't work.
I made a python script that accesses the file from serverA on serverB. It works if I run that script from CMD, but when I run that script from PHP code it doesn't work anymore.
I run IIS server as a domain account that has access on serverA
I try to run that as LocalService, NetworkService, System, LocalUser but no success.
That script is a simple open command, so problem it's not from python.
Since you provide no example code or describe what you are doing... There are a few things to consider.
Anything running in the context of a webpage in IIS is running in a different context than a logged in user.
The first part of that is simply what file system level permissions might be different for the IIS user account. The proper way you want to handle that is by assigning the necessary changes at the filesystem level for the IIS user. Do not change the IIS user if you do not understand the ramifications of doing that.
The next part is that certain operations cannot be done in the context of the IIS user account (regardless of account permissions), because there are certain things that only a logged in user with access to the console/desktop can do.
Certain operations called from IIS are purposely blocked (shell.execute) regardless of permissions, account used, etc. This occurs in versions of IIS in Windows Server 2008 and later and is done for security.
Resolved.
Uninstall IIS and use XAMPP.
No problem found till now, everything works okay.
So use XAMPP/WAMP!
We have a small office intranet, built in PHP (on an apache server - so WAMP), that allows us to create project folders on our file server. This works by copying a set of template folders to a new location using the shell exec xcopy command and the following switches /e /k /i /c.
We (fairly) recently upgraded to a new file server running Windows Server 2008 R2 Standard. Now the xcopy command no longer works from within PHP. However, I know that the xcopy command is correct because it works if I copy and paste it into a command prompt (on the same machine).
I can see no error message but I assume this is some kind of permissions issue related to the PHP 'user', but I don't know exactly what or how to solve it.
The apache server and the file server are two separate machines. If it's relevant, the apache server is a 32bit machine and the file server is a 64bit machine but, as I say, I can invoke the xcopy command from the CLI of the 32bit machine without a problem.
The Apache process user name is SYSTEM (although I can't seem to use the 'whoami' command to check this)
Any pointers would be greatly appreciated.
FWIW, the exec string looks like this...
echo "xcopy \"\\\\path\\to\\folder\\xxxx_Project\\*.*\" \"\\\\path\\to\\folder\\9876_NEWPROJECT\" /e /k /i /c";
which (I think) materializes as this...
xcopy "\\path\to\folder\xxxx_Project\*.*" "\\path\to\folder\9876_NEWPROJECT" /e /k /i /c
Obviously, the '9876_NEWPROJECT bit is really a variable.
OK. I seem to have got it working. Here's what I did - tell me if it's a bad idea although I should point out that this is an intranet so I'm a little less concerned about security...
Go to Control Panel->Administrative Tools_>Services
Select the Apache service and hit Properties
On the Log On tab, click 'This account:' instead of 'Local System account', and then find the User account of Windows user who's normally logged on to that terminal
Restart Apache
I also amended the user info in the httpd.conf file, but I'm not actually certain that that was necessary.
If there's a better solution, that can be explained in words of two syllables or less, I'm all ears!
get_current_user() will confirm the user your script runs as.
Then try to manually execute your command as this user with runas (or if your user really is SYSTEM then you will need something like psexec to do so).
Now, assuming that your script actually runs as SYSTEM, it is very likely that this user is not authorised on the remote file server. I don't think it is even possible to do that (except, perhaps, by allowing "Everyone"). If it is, I am not sure this is a good idea anyways.
I would instead run the apache service as a regular user, and on the file server, grant access to this user.
Alternatively, you could mount the remote location as a network drive (not tested, other answers in the thread might help too).
I know this is a simple question, but I can't for the life of me get it to work. If I log in to my server via SSH (linux) and type in : /home/username/public_html/x/foo.cgi f=subscribe l=list e=abcd#gmail.com the script runs perfectly. However, if I try to run the script via PHP by the likes of : shell_exec("/home/username/public_html/x/foo.cgi f=subscribe l=list e=abcd#gmail.com"); nothing happens.
Can anyone point me in the right direction?
Thanks ahead of time!
Tre
"Nothing happens" isn't a very descriptive error message. Nevertheless, three possibilities come to mind:
Differences between the server-hosted environment versus the shell environment.
Your server or hosting site may have disabled shell_exec or other functionality.
You may need to be running PHP as the same user you SSH'd in as (or otherwise get the correct permissions).
Some other piece of the stack are in disarray due to mis-configuration or misuse.
Take your pick. Check your logs. Make sure you don't leave any holes available for attackers to get in.
If you are managing the server, most likely this is a permissions issue. Your webserver is running as www-data or some similar user. It needs execute permissions on the script file to run it. Try changing the script's owner with the chmod command or give the file you're trying to run more liberal access permissions with the chown command.
Another thing to consider is that shell_exec may be disabled if PHP is running in safe mode.
I am working on an application that runs locally on a Fedora 10 machine through PHP and Apache. It depends on a process that runs in the background.
The higher-ups want to be able to start/stop/restart the process, through the browser. I was trying to get this to work by having PHP make calls to the system using exec() and shell_exec, but it doesn't seem to work.
When I try to start the process using "exec('processName')", nothing happens.
When I try to use "exec('killall processName')", SELinux starts constantly popping up warnings that the process was permitted (because I put it into permissive mode), however it doesn't actually kill the process! But this seems to go on even after the page is fully loaded!?!?
I AM able to call another script in a similar fashion: "exec('/var/www/cgi-bin/ControlProgram START')". So I'm not really sure what the major differences are between the two calls/commands.
I also put the script call into the /etc/rc.local file to have the script run at login. However, will I be able to kill this script from PHP since its run by... the system?
I'm not a guru when it comes to permissions/SELinux, so don't spare on the gory details! Thanks in advance!
If you have administrative control over this system you will want to check the PHP configuration (make sure it is the config profile for the web server).
Safe_Mode will prevent PHP from executing anything outside a particular folder. In a shared hosting environment, this usually means you can only execute things that are relative to your home/www folder--which seems to be the case based on your notes.
I believe I found the problem. I'm still not exactly sure what the problem is, but it looks like it has something to do with file/directory permissions. When I moved the scripts into my /var/www/html directory, the scripts ran. I moved them into /var/www/cgi-bin and they work there too. So it might be something where apache can't execute scripts that are outside the /var/www directory, or at least it can't do it directly. Thanks for your help though!
It sounds like old school unix permissions and how apache operates. I do recall (though it has been some time) that apache is careful on what it will execute. Double check your octals.
To verify that it isn't SELinux you can disable it instead of putting it in permissive. though this will cause a file system relabel (or should). At that point your extended attributes with the SELinux contexts could get out of wack and cause SELinux problems once in enforcing again.