I have been trying to change the permissions of new session files. According to this page, I need to change the mode in the session_save_path configuration in the php.ini file. I have changed it to 0777, the default is 0600. New session files are still being created with 0600 permissions. I have checked, the correct php.ini is loaded and the changes are saved. I have configured it like: 0;0777;/var/lib/php/sessions (N;MODE;/path). Can someone explain to me why the files are still created with 0600 permissions, while I have configured it to 0777?
The files are stored in /var/lib/php/sessions and I'm using Codeigniter.
The /var/lib/php/sessions/ directory typically has the "sticky" bit set on it -
drwx-wx-wt 2 root root 4096 Oct 15 11:21 /var/lib/php/sessions/
This is done via chmod 1733. Remember that using the setuid/setgid/sticky bits on a directory effect how files are created (default owner/group and permissions) in that directory and any sub-directory, regardless of system umask values, etc.
From this page - http://www.filepermissions.com/articles/sticky-bit-suid-and-sgid - which is part of a 3 article series on *nix file permissions which is pretty good.
A Sticky Bit, is a special setting within file permissions that helps
limit access beyond what normal file permissions are capable of. In
short, a Sticky Bit ensures only the owner of the file / directory is
able to delete or rename the file. However it should be noted that
root is able to edit and delete the file as well.
With the mode of 1733 the session data files can't be read by others on the system. This is a Good Thing.
Why do you want world readable session storage?
Edit -
If you really want to break it, create a new directory w/ appropriate permissions and change the session storage path to use that directory. Note that there may be an internal check in PHP that will make it refuse to store session data in a place it considers "insecure", much like SSH refusing to use keys w/ insecure permissions.
Related
I am using Jasperreports for generating the reports. When I am generating the new reports it will be own by root with permission of 644. So other users dont have permission to view this report.I want to change the ownership of the file or change the permission.So everyone can view or download the reports.
I tried below php functions
chmod($item, 0777);
chown($path, 'www-data');
It gives
error: dont have permission to do this
. Because its own by root and current user is www-data.
Anyone please help me,
Actually, based on what you're saying, all users have permissions to view that file. 644 means owner can read and write, and group and others can only read. If your script is getting an error reading that file, it might be because of the permissions of the directories in is path, but not the file itself.
If you could change the owner or permissions of a file owned by root like that, it would subvert the whole concept of unix file permissions. Think about it.
You can always change the user running these reports though, or add logic on the report generation side to move or change the permissions on the file as the user who owns it.
As an aside, chmod 777 is an ugly kludge used only by those who have little knowledge of unix permissions . Professionals don't do it. You should bump your understanding of unix file permissions to the next level:
https://www.tutorialspoint.com/unix/unix-file-permission.htm looks promising.
According to the manual, the owner and the supersuer have the right to do this.
And you only chage the file mod or owner, will not do. You have also to change the path.
chown
Attempts to change the owner of the file filename to user user. Only
the superuser may change the owner of a file.
Note: This function will not work on remote files as the file to be examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or directories being operated upon have the same UID (owner) as the
script that is being executed.
chmod
Attempts to change the mode of the specified file to that given in
mode. Note: The current user is the user under which PHP runs. It is
probably not the same user you use for normal shell or FTP access. The
mode can be changed only by user who owns the file on most systems.
Note: This function will not work on remote files as the file to be
examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or
directories you are about to operate on have the same UID (owner) as
the script that is being executed. In addition, you cannot set the
SUID, SGID and sticky bits.
What permissions do I need to set up on a directory in order to make it writable by php?
By "writable", I mean copying and creation of new files within that directory automatically by php itself.
I'm testing this on a free host, and the default permissions are 755.
When I try executing a php script, that attempts to create another subfolder of that directory, and copy certain files in it, and it fails.
If I set it up to 777, it works fine, but I assume that doesn't work on all Apache versions because of security reasons?
Also, when creating new files, does php act as the "owner"?
Whatever process that runs the PHP interpreter should should have a user account associated with it. Only that user needs write permission in the directory. So to answer your last question, it's usually www-data or apache that is the owner of that file.
Permission of 777 will work because it allows everyone to read, write and execute that directory but depending on your application this might be a security hole.
What is the purpose of using umask(0); in php?
I have seen this a few times, and cant figure out from the documentation what it precisely does.
Can someone explain this and when it would be useful to use?
Setting the umask to 0000 (or just 0) means that newly created files or directories created will have no privileges initially revoked. In other words, a umask of zero will cause all files to be created as 0666 or world-writable. Directories created while umask is 0 will be 0777.
Usually when you see umask(0) it should be followed directly by a call to chmod() to explicitly set the permissions needed on the newly created file or directory to something other than world-writable.
Use caution when setting the umask to zero! This can be dangerous and is mostly only useful for creating files which must be later written to by the web server, when the web server runs as a different user that a "real" user who will also need to be able to modify the files created by the web server. Otherwise, the system's default umask is likely to be something like 0022, writable by the file owner but not others. In that case, if you logged into the machine under a normal user account, the file created by the web server under PHP would not be writable by you.
Rather than creating world-writable files, it is generally a better idea to manage the directories the web server is writing to more explicitly. If the files created inside a directory should have certain group permissions, it may be advisable to set the sgid bit on the directory so new files inside it inherit group ownership. Users needing access to the file should be members of the group having access to it. This is much more secure than creating world-readable, world-writable files.
php > umask(0);
// Should get created as 666
php > touch('file1.txt');
// "2" perms revoked from group, others, gets created as 644
php > umask(022);
php > touch('file2.txt');
// All revoked (2,4) from group, others, gets created as 600
php > umask(066);
php > touch('file3.txt');
-rw-rw-rw- 1 me group 0 Aug 24 15:34 file1.txt
-rw-r--r-- 1 me group 0 Aug 24 15:35 file2.txt
-rw------- 1 me group 0 Aug 24 15:37 file3.txt
The umask is basically a default setting for creating files. In essence it is safer to turn your default chmod on and then write the file than write it and then chmod it (some say). At the end of the day the time between finishing writing the file and running chmod would be miliseconds at best so I am sceptical about this.
umask() sets PHP's umask to mask & 0777 and returns the old umask
It basically sets default write permissions to whatever you put in on OS's such as Linux and then returns the old one so you can reset it back. This applies to the PHP process itself.
The comments on the doc page: http://php.net/manual/en/function.umask.php will clarify by example.
I am working on a PHP based website. In the admin there is a section that checks a form field and based on the field looks for a folder on the server. This folder will be in a sub-directory. If it does not exist it needs to be created. After that, previously existing or not, PHP will write file to the folder.
These folders will hold images and PDF files that will be viewed and/or downloaded on the main site.
Here is an example directory structure: merchants/east/user123
In the above merchants and east would definitely exist and user123 may exist or otherwise be created.
Given that info my questions are about folder permissions.
What should folders be set to for the best security.
Should I open them up wider during operations then chmod them (in PHP) after I'm done to something more secure?
What should upper level folders be set to?
770 would be a safe bet for the files. Setting it to that would disallow any public access. I would implement some sort of document delivery system in PHP. PHP will be able to access the non-public files and then send them to the user.
The upper level folders could be set to the same.
Update
As others have said, you can easily chmod them to 600 without any issues. That's the more secure way of handling it (prevents other users on the system from accessing the files). It also omits "execute", which isn't needed for file reading anyway. It's my personal practice to leave the extras in unless there's a defined reason not to.
The upper level folder would need to have read, write and execute permissions for the apache user., the top level folder could be owned by apache, and have permissions like 755 to allow the the webserver to read, write and list files.
You might think about permissions 750 or 700 if you are particularly concerned about other local users or services on the web server from seeing the files in this directory.
For file permissions: 644 or 600 as conventionally they do not need execute permission.
A nice compromise might be to use 750 for directories and 640 for files with owner set to apache, and change the group (chgrp) so that the group for the file allows access to the user that you normally edit the website files with.
I can't think of any significant advantage of the php script increasing and then reducing the permissions.
I think you should consider #chunk's comment about keeping the uploaded files own of the public html directory completely, and serving them back via an file delivery script. Otherwise you would need some careful validation of the content of the files and to tightening up the apache configuration for that particular directory - perhaps using some mimetype checking to make sure that the files really are docs and pdfs.
Scratching my head on this one, seems so basic.
I've got a PHP based content management system for our website written by a contractor. One feature is the ability to upload images to be displayed in various places on the website (like a product gallery). All such uploaded images are stored in a particular directory called "attachments".
drwxrwsr-x 4 www ftpusers 4096 Oct 10 14:47 attachments
As you can see I've got the setgid bit set on that dir so that any files written will have the group that users (like FTP user) who need access to those files will able to modify/overwrite them. I've set the umask for Apache so that it will write files as group writable.
When I try this with ANY user in the system by creating a new file in that directory, it correctly inherits the group of the parent. When a new file is created through PHP running in Apache, it always has the apache.apache ownership. Apache seems to be ignoring the setgid bit, which I didn't think it could do as this was done by the file system. Here is one file I uploaded:
-rw-rw-r-- 1 apache apache 30536 Oct 10 14:43 209
I can't test as the apache user directly as it doesn't have a login shell specified (for obvious security reasons).
I can get the same permissions capability by adding the ftpusers group to the apache group, but this doesn't seem wise from a security perspective.
I did find one thing that seemed like it might be related - php safe mode, which I've verified is off in /etc/php.ini, although I'm not positive I found the php.ini file that mod_php in apache is using. The php script is using move_uploaded_file(); as far as I can tell, nothing fancy with permissions is being done in the php code.
My best guess would be that this is an intentional limitations for security, but I can't find anything that seems to indicate that is the case.
Running CentOS 5.6 with Apache 2.2.17 and php 5.2.16.
Anyone have a clue?
When you upload a file it is created in the dir specified by the PHP's "upload_tmp_dir" setting. Then move_uploaded_file() moves it to your target dir. It maintains the permissions given to it upon creation and not those of the target directory you move the file to.
So you want the tmp dir to have the permissions you want, basically those you've given to your target dir. Then it will be created with the setgid having effect and the move will keep them.
IIRC "upload_tmp_dir" is not available in .htaccess so if you cannot change this setting or the permissions given to the dir then you will need to do it another way.