I have the following code:
mkdir($thumb_dir)
which creates a directory in the proper location, but when I view the permissions it is
Owner : nobody
Group : nobody
I don't have shell access to chown. How do I prevent the user assigned as nobody and how do I delete the folder that I have already made since I don't have permission.
It's a godaddy shared server...
you can delete empty directories with rmdir().
nobody is the user that runs the apache process. You can't change the owner from within php, nor you can delete the folder using shell access (or make any changes on it whatsoever) without root permissions; you can manipulate it only through php
This happens because the Web server is run by the nobody user. Therefore, everything you do on the file system will be done with the privileges of nobody.
There is typically no way for you to change anything about that. You'll have to manage with the Apache user being different from the FTP user you have. If you create a directory with PHP, you'll only be able to delete it with PHP (using rmdir() when the directory is empty), and if you create files you will most likely have to delete them from PHP as well.
I suggest that you create your directory structure with your FTP user and keep as little PHP-generated content around as possible because of that.
You can alleviate the symptoms using permissive authorizations (with chmod), but that's generally not a super good idea security-wise.
Use rmdir($thumb_dir); to delete it.
You cannot change your PHP user on a shared server.
Related
This questions comes from my poor knowledge of server-side web development, but I'll try to make it as clear as possible in order not to make any mistake in my server configuration.
I have a web application that at the press of a Download button should trigger a php which in turns will write a file to a directory and let the user who clicked download that file.
This directory will store temporary files and should be cleared periodically.
So my doubts are:
Where is a good place to store these temporary files (in /var/www/<my_app>/tmp?)
Should I grant the apache2 user (www-data) read and write permissions to this folder?
Did I miss anything else?
EDIT1
Just saw php passthruw command. Will this be enough for zipped files and let me avoid thinking about the tmp folder and permission?
1) that temp folder could be created wherever you want.
2) when you have a php script and user clicks some button in front-end application and triggers that php script to run, that php script gets executed on behalf of apache2 user which in turn is the 'other - world permission'. (There are users,groups and others). So you should grant write permission to others in order apache2 user(www-data) to write to that directory.
This way you can't upload a file via ftp or sftp or whatever, because with ftp , your user won't be www-data. and remember what you did. you gave the write permission to only www-data.
To better understand this concept, I'd advise you to read the following link and the answer too. File permissions for Laravel 5 (and others)
So I have a PHP application. The permissions are set to appropriate ones for www-data user and group. The problem is that I have files being generated by another server process (a java process) running under a different user that PHP needs to access. They are also in another directory not registered with the vhost.
So I'm trying to figure out the best way to do this. I think I can create a symlink to that directory in my php folder that's already accessible via the virtualhost (checking to make sure apache is following symlinks). So then I will still have to change the permissions on the actual files, right--maybe add www-data to the group that creates those files? Does that mean www-data would potentially have access to all the files owned by that group? Are the apache directory permissions enough to prevent a potential attacker from moving outside the directory with those specific files I want served?
Alternatively I could create a new virtualhost that runs under the user that owns those files, and just access the files via a different subdomain.
I could potentially see about creating the files as owned by the www-data group and having group read permissions on the files.
Anyway, just seeing whether there's a standard best practice for this issue.
I have a php script that needs to create/delete files within the /www/mydata directory (using centos+linux+apache).
I gave the "apache" user ownership of www/mydata to allow this.
Is that secure enough? Is there a better method? I would much prefer that ONLY the specific script have "ownership" of www/mydata and only while it's running, in case someone is getting up to shenanigans.
Can that be done, or am I stuck giving the apache user all these privs?
Edit: to forestall a few obvious answers, I have attempted to have the script create the directory (it can't) and I've also attempted to set the directory permissions in the script on the fly using PHP's chmod (no deal).
The "Apache" user you mentioned can be ANYONE from the Internet that running the script. If you want to secure the "www/mydata" directory, you can try to check the user's privilege before they execute the actual "create/delete" actions.
Good day everyone.
I am building a Laravel 4 application and I have some file permissions issues.
Once the file has been uploaded by the client, it's moved in a folder. However, the file gets very little permissions, is assigned the user www-data and can't be touched / moved by anything else.
I need to know how to dynamically permit laravel to have permissions on those files because I'm using CloudConvert to convert this file.
I'm on Ubuntu 14.04 also and my prod is on debian. I already tried to chmod -R the folder, which works for files already saved, but when new ones are created, it doesn't work anymore and stays in www-data ready-only low permissions.
Thank you for your answers.
EDIT : I might have found something : chmod g+s with given permissions. I read it gave recursive permissions to created files. I'll try once I'm home.
That account "www-data" is the default account for the web server. That is why it becomes the owner of the files and has full access to them, from a web angle. If what is happening is that you are trying to then convert the files outside the web context (like a cron job or something) then you need to make sure the same user (or maybe a group) owns the files. Have not tried CloudConvert (looks cool, will check it out) but maybe you can leverage Laravel's queues and that way execute your conversion with the web server's "www-data" account?
It was a stupid mistake on my side, I'm afraid.
I was renaming the file before curl could pass on it, making it unable to know what was the original file name (getClientOriginalName()).
I need to call a PHP script from a remote computer which will invoke the remote server to change a DNS record. Is this possible? I have everything working fine in test environment but PHP doesn't have access to /var/namdd/mydomain.com.db. It's a VPS of mine that I have root access to so getting access isn't a problem. I just want the script to do it for me. Any ideas?
Assuming the other server is running BIND, the files could be owned by named, not root. Would be a much simpler option. Also, you could make them 777 and then have PHP simply edit them.
Three ways immediately come to mind:
Changing the permissions of the file.
Creating a daemon to do it.
Creating a command and configuring sudo to run it without a password.
Changing the permissions of the file
The simplest case would be to change the permissions of the file. To do this, you'll probably at least want to know
the user reading the file, and
the user your PHP script runs as.
If the users are the same, then of course the answer is simple: change the owner to that user. Otherwise, if the file contains no sensitive information, you might be able to change the owner to the PHP user and grant read access to all users. Finally, you might be able to create a new group containing those two users and change the group of the file. Then you could change the user of the file to the PHP user and grant write permissions, change the group to the group you created and grant read permissions, and grant no permissions to everyone else.
Creating a daemon to do it
This is rather involved; I can't say I would recommend this option. Essentially, you have a background process running with whatever privileges are necessary. This process can do whatever needs to be done and communicate with processes of lesser privilege. When the PHP script needs to modify that file, it can send a request over to the daemon, which can then change the file on behalf of the PHP script.
Command with sudo
This is probably one of the best ways to do it. Essentially, you'll need to create some command that does whatever you need to do with the file; then, once you know it works when run as root (or preferably some less privileged user which still has the necessary privileges), you can configure sudo to let the PHP user execute it as the more privileged user without a password.