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()).
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)
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.
I am writing a PHP code that creates another PHP file with fopen and writes to it. It runs on most shared environments without any problem but in some old servers and customized servers the code fails to create file and write to it even though the folder permission is 755 as the PHP runs under the account 'nobody' and the folder owner is another user.
In shared servers the folder owner and the PHP both runs under same user and so there are no permission issues.
Can anyone help me out here with a solution please.....
Thank you All...
EDIT: This problem might have bugged many others including packages like Joomla, Drupa, etc. How do they get around this problem? Can anyone explain please. Thank you.
If PHP runs as user 'nobody', but the folder you're trying to write in belongs to a different user, the only way to have write rights to that folder would be if 'nobody' is in the same group, of if the folder has permissions 777 (write rights for everyone).
There is no direct solution to this problem. So the only solution was to show the user a relevant message and ask them to copy the files manually...
I'm developing a WYSIWYG type site builder in JS for people who don't know HTML/CSS. It's all done, but I want to make this as simple as possible. In a perfect world, they'd just upload all the files to their host and be done with it. The problem I'm having is, I have some files and folders that need writing to, but PHP doesn't have permission unless I CHMOD those specific files and folders to 777.
I really don't want to do this and was hoping I had some alternative, nor do I want to be criticized for forcing CHMOD 777 upon everyone. Is there anything I can do (that would be simple for my users) to allow PHP to write to files/folders without having to grant permission to EVERYONE?
I can't have PHP create the files/folders itself because it doesn't have access to write to the root directory either.
You could chgrp the files to the web server's group (or PHP's, if it's set up to run as its own user) and chmod 770 them. But that wouldn't get you much securitywise.
Alternatively, you could do what some other PHP CMSes (like Joomla) do -- when a file needs to be modified, have the server connect back to itself via FTP (with the site owner's credentials) and upload the replacement file.
Truth be told, though, any way you choose to allow people to modify files on the server is going to have its pitfalls, and securitywise will generally be almost as bad as making the whole site world-writable. No matter how you do it, i suggest you make damn sure your authentication and access control mechanisms are up to snuff, as you're taking those responsibilities upon yourself especially when you allow web users to edit files.
Have the users CHMOD 777 the root directory, have your script create the new folder, and then have them restore the root directory's permissions.
i have to admit, i never really completely got the *nix filesystem permission model. oh, the rwxrwxrwx stuff isn't too complicated, but i get confused easily when programs create new files and how i can handle them.
my current problem is the mixture of a (closed source) java-applet that does file uploads over ftp and php (it's on a dedicated server and the data isn't really critical, so i'm not all too concerned about world-writeability).
so, i have two users: ftp (1000) and apache/php (81). groups don't match, so they're basically "others", if i'm correct.
an "import" directory, set to 0777 owned by ftp.
if a visitor acesses the upload page, a subdirectory named after his username is created by my script. let's say, the visitors username is "foo", so it's "import/foo", set to 0777, user 81/php.
next, the visitor uses the java applet to upload a file to this directory (test.jpg). the file's permissions are now rw-r--r--, user ftp.
first question
the first thing i don't understand is: i'm able to unlink that file through php.
why? the users don't match, and the file isn't world writeable.
is this because of the parent directories world-write permission? understandably, i can't chown or chmod through php.
so far no problem, because as long as i can read and unlink, everythings ok.
second question
the java applet is able to upload whole directories, which is nice. if i do this, the new subdirectory import/foo/test has permissions rwxr-xr-x/ftp. the files in this directory are rw-r--r--/ftp.
now i'm out of luck. i can't do anything with those files (besides reading, which i do successfully), no unlinking, no chmod/chowning. they just sit around and gobble up diskspace.
so, what's the plan behind the default-permissions new files have? my guess is they have the permission set through umask, as long the creating script doesn't chmod them to something else. am i right?
third question
what can i do about it? i mean, what would a sensible person do? can i/should i change the umask for the ftp user? (i just learned about umask yesterday). i'm not very comfortable with this, as this would affect all ftp traffic, doesn't it? also, the server is dedicated but i'm not an admin, so my access is restricted.
i just had another idea. before starting this post i read up on the basic linux permission stuff. first, the sticky bit isn't set anywhere in the directory chain. and then, there it was: the "set user ID bit".
so, my current plan is to write a simple shell script with owner ftp that is other-executable with setuid. the script just transfers the file in the import directories ownership to user php.
then, after each import i just exec() that file from my php-script and process files further.
would that work? and more important: is that clean and legal? or would the sysadmin put a bounty on my head?
thx a lot!
update: i just tried to set the uid bit (4755) through winscp (through an ftp connection), but it somehow doesn't work - it seems to "forget" only the uid bit (the other bits get set). why is that? why can't the owner set the uid himself? is that server-specific or generally the case?
update 2:
wikipedia says it all
Due to the increased likelihood of security flaws, many operating systems ignore the setuid attribute when applied to executable shell scripts.
is it still possible for user root to set the uid-bit?
First answer
Correct, you have permission to modify the directory so you can unlink the file. Whether that file is readable or writable to you is irrelevant.
Second answer
Yes you are correct that the user's default umask will be used unless the script/applet then chmods the file permissions to something else
Third answer
Setting the default umask for ftp is the simplest solution, but as you say this affects all files then created by the ftp user. If that user is only used for the upload via the applet (and it should be really) then this isn't really an issue I'd say.
The other option is to have a cron job running that executes a script (like you suggest), chmoding/owning the files (and maybe virus scanning them etc) from the FTP upload area to somewhere on the webroot.
You don't state why having these files readonly to Apache is an issue (or is it the fact that the FTP root isn't under the web root?), maybe clarifying that would help point to a sensible solution? Generally you don't want to trust anything the user has given you unless you've vetted it first.
EDIT - just seen you're not an admin of the machine which makes things difficult.
what i learned today: the setuid bit is often deactivated for scripts.
the solution i've settled on: apache/php gets sudoer-rights for certain scripts (all scripts in one directory outside the webroot) that may run as either the ftp- or apache-user. i can then call those scripts with sudo out of php with system/exec/etc.
i didn't know sudo could be configured in this way. amazing