How I can change owner of files written by php - apache

How can I change the owner of the files written by php from terminal (command line)? The files are created by upload form in apposite folder.
Many thaks

Use the command "chown":
chown owner filenames
To solve this problem in the future uploads, you can use the chown command:
chown($path, $user_name);
http://php.net/manual/en/function.chown.php
There is also a chmod command, if you prefer to change permissions:
http://www.php.net/manual/en/function.chmod.php

Maybe you can change the owner within the PHP program itself (of course if you have the permission to do that) with the exec command of PHP.
For example:
exec('whoami');
See the documentation of this php instruction here: http://php.net/manual/en/function.exec.php
This could work, but only if the servers configuration allows so.
If this doesn't work, you can try also this, but again you need some priviledges to do it:
// File name and username to use
$file_name= "foo.php";
$path = "/home/sites/php.net/public_html/sandbox/" . $file_name ;
$user_name = "root";
// Set the user
chown($path, $user_name);
See the documentation of this php instruction here: http://php.net/manual/en/function.chown.php
There are some instructions in php to modify file attributes like, chmod, chown, among others.

Related

Run exec()/system() etc command using PHP & OpenBSD

I am trying to run a simple command say ls -l on OpenBSD shell (uname -r: 6.4) using php 5.6.
<?php
$output = shell_exec('ls -l');
echo "<pre>$output</pre>";
?>
There is no output of above code. Just pre tag upon inspecting elements
So what is causing this issue? I tried using the same command using
System
Shell_exec
exec
No luck. What would be the cause of this ? Probably System/shell_exec not supported in OpenBSD's version of Php or something else.
Thanks in advance!
You haven't given enough information for a definitive answer, but my
guess is that you run php through php-fpm, which is by default chrooted
to /var/www. Since shell_exec and system first call /bin/sh and you
most likely didn't copy it to var/www/bin/sh it can't find your shell.
After that you'd also need to copy the binaries (in this case ls) to
your chroot and possible library dependencies (not needed for files
under /bin).
Hope this helps for illustrative purposes, but please don't use it in
production.

please tell me how you set permission 777 on serverfree.com without SSH

anyone can please tell me how you set permission 777 on serverfree.com because i am seen there and there is not any option to set permission and unable to set permission via web based ssh.
please tell me how you set permission.
actually everythis is fine on serverfree.com but i am unable to set cron, someone tell me it's permission issue , but i don't know how to set permission on serverfree.com without SSH ?
Usually, you are able to set the permissions via your FTP-Client.
e.g. in FileZilla there is an option "File permissions..." where you can set the permission values for each file.
You're on a *nix System, right?
If you only want set permissions without calling chmod directly(as your question suggests), you can try following on the console, if you have Perl installed:
perl -e 'chmod 0777, "Filename"'
Another approach is to use the install utility which is a glorified copying program which can set permissions in one step. (See the -m argument.)
install -m 777 "File" "/Copy/Location"
You can find it in the GNU coreutils(if you have it installed there), and isn't directly included to *nix systems(but BSD for example). Also simple move the file out of directory and call install to move it back.
But for both methods you need SSH, and i don't think there is a solution to set permissions without(because you never can do the chmod() system call that you need to set them).

Can't log in into trac

So I am trying to use trac as standalone bugtracker. I've generated user and password using script on this page. digest.txt file is in ~/.foo-trac/conf/ directory. Source looks like this:
montreal:FOO:904fa5b01944434358e48467fbf5203c
Running this command:
tracd -p 8000 --auth="foof,.foo-trac/conf/digest.txt,FOO" ~/.foo-trac/
Getting no errors but still not able to login. Strange detail is that tracd shows this line when I'm clicking log in:
127.0.0.1 - - [16/Oct/2014 03:47:53] "GET /.foo-trac/login HTTP/1.1" 500 -
What's going on?
UPD
Now I am trying to make it another way: using base auth on this page.
I've created new environment by this command: trac-admin /home/montreal/.trac initenv. In prompt I've given name Foo to my new project.
Then I've created new user by running this command: sudo htpasswd -c /home/montreal/.trac/.htpasswd username and entered a password. My .htpasswd file looks like this:
username:$apr1$bLbNsCx/$vbVXn5gn6HG.hJvvq/SaD1
Now I'm runnig trac by this command and getting the same result:
tracd -p 8000 --basic-auth="Foo,/home/montreal/.trac/.htpasswd," /home/montreal/.trac
Link says that first argument of --basic-auth should be projectdirname, but in /home/montreal/.trac no Foo directory.
It looks like I've got correct /fullpath/environmentname/.htpasswd argument.
But how can I get the realmname argument? Maybe it makes all the trick. Maybe some logs of tracd can be helpful but log folder is empty and I don't know another place to look.
I need this bloody bug-tracker.
Don't use relative paths (~/.foo-trac/) but absolute ones.
Same applies for the auth file path, that is not even relative like the path to your Trac environment but certainly wrong, because its absolute path is not /.foo-trac/conf/digest.txt, but this is what tracd is picking up from command-line as you see in the "strange" log line.
Enable Trac DEBUG logging in .foo-trac|.trac/conf/trac.ini as advised in the wiki documentation on this topic.
First argument of --basic-auth should be projectdirname, that is /home/montreal/.trac itself, commonly referred to as Trac environment directory, nothing else.

How can I read files outside the cgi-bin folder?

I've written a cgi script that processes data that is generated by another program. The problem is that this file is located outside the cgi-bin. How can I make sure that my perl scripts can read this file? I've already tried changing the permissions of this file and I also tried to make a link in the cgi-bin folder but Apache is too smart for that. I guess possible solutions are:
Edit the Apache config file in a way that Apache can read files outside the cgi-bin.
Run the cgi script with a 'portable' webserver. Like you can do with python (python -m http.server [port]). Unfortunately this does not execute the perl cgi scripts.
I'm kind of stuck how to do either one of the solutions.
Your CGI-script could access anything on your OS unless you run the apache under a sort of jail, in this case the your can read anything in the jail. (Of course, if the apache process has permissions to read the file).
e.g the next simple script will print out your password file
use strict;
use warnings;
use CGI;
my $q=CGI->new();
print $q->header();
print qx(cat /etc/passwd);
About the modern perl web-app development, read the following:
PSGI: What is it and what's the fuss about?
plack advent calendar: http://advent.plackperl.org/2009/12/day-1-getting-plack.html (buy the ebook if you can here: http://handbook.plackperl.org )
https://github.com/plack/Plack
Get some modern web-framerowk from CPAN - here are many (maybe too many) - the most known are:
Dancer (Dancer2)
Mojolicious
Poet/Mason
and of course, the big-gun: Catalyst
I personally mostly using
Poet/Mason
Mojolicious
EDIT
In your cgi-bin should exists a script called printenv.pl. Try:
chmod 755 printenv.pl
and point your browser to http://address/cgi-bin/printenv.pl You will get, the apache environment. See, you must know the basics of operating system commands and how the web works to succesfully run an web-application. It is impossible to write down everything in one answer, you need to use google, read answers to other questions here and such.
Also, in the above script, you can change the cat /etc/passwd to any other shell command for testing only what your cgi-script can or can not.
I've solved this problem by using plackup in combination of PSGI.
use CGI::Emulate::PSGI;
use CGI::Compile;
my $sub = CGI::Compile->compile("location/to/script.cgi");
my $app = CGI::Emulate::PSGI->handler($sub);
If you run plackup file.psgi, it sets up a local webserver that runs as the current user. Problem solved.

Postfix piping email to php, permissions error

I'm attempting to pipe an email to PHP with my Postfix mail server, using the technique mentioned here and have encountered the following error...
Mar 16 22:52:52 s15438530 postfix/pipe[9259]: AD1632E84C63: to=<php#[myserver].com>, relay=plesk_virtual, delay=0.61, delays=0.59/0/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /bin/sh: /var/www/vhosts/[myserver].com/httpdocs/clients/emailpipe/email2php.php: Permission denied 4.2.1 Message can not be delivered at this time )
I'd really appreciate if anyone could shed some light on this issue for me. I've tried 777'ing the emailpipe directory, to no avail. Where am I going wrong?
Many thanks.
From the postfix docs...
For security reasons, deliveries to command and file destinations are performed with the rights of the alias database owner. A default userid, default_privs, is used for deliveries to commands/files in root-owned aliases.
So you have two options, either set the default_privs in main.cf to match the ownership of the email2php file.
Alternatively, there should be a way to create an alias database that is owned by the user instead of postfix/nobody. I haven't tried this before though so can't advise.
I have fixed this issue by disabling the SELINUX.
Make sure that you have
#!/usr/bin/php
<?php
(or whatever your path to php is - do "which php" on the server)
at the top of each of your php scripts and that each of the php script files is executable
chmod +x /var/.../email2php.php
Also, make sure that you can test the script from the command line:
cat some_rfc822_email.txt | /var/.../email2php.php
and get the result that you want
To fix this issue, you'll want to chown or chmod /var/www/vhosts/[myserver].com/httpdocs/clients/emailpipe/email2php.php to executable by your postfix user. Alternately, you'll want to redefine this user to execute the file successfully.
Simply changing the permissions of your directory (unless you used -R) won't be sufficient.
To illustrate why this works, consider the following toy example:
<me>#harley:~$ touch test
<me>#harley:~$ ls -al test
-rw-r--r-- 1 <me> <me> 0 2012-03-26 23:44 test
<me>#harley:~$ sh test
<me>#harley:~$
<me>#harley:~$ ./test
bash: ./test: Permission denied
<me>#harley:~$ chmod 755 test
<me>#harley:~$ ./test
<me>#harley:~$
In order to execute a file directly through the running shell, it needs to be set as executable. Other invocations (for example, sh email2php.php or php email2php.php) only require read access, because they're chaining execution off a different file entirely.
For what's likely to be causing the issue in the first place, see here.