Noticed this when creating a new directory in unix, and was just curious as to why this is so.
Thanks
A new directory created by a user and owned by the user with full permissions is no big deal. However, a new file/program if executed accidentally or before configuration could have catastrophic results. So the designers decided to give you a layer of protection.
It also prevents other users from executing the file unless you specifically grant permission.
Because you need the executable permissions to naviguate into the directory.
So basic permissions allow user to read file (read file permission), and to access file in directory (directory execute permission).
Note that read permission on a folder allow user to list files in it. (But doesnt allow to read them unless execute permission is granted too as I said in the first place)
Basically, +x on a directory means that the user can 'execute it' hence change into it (replace user by group or other depending on position in permissions).
Hence drwxr--r-- means only user can change into directory. More here.
The directory needs to have executable permissions so you can do things such as cd into it. Also the executable permission lets you look into the directory for inode information of the files it contains.
More info can be found at this source.
Related
You need to make this file writable before you can save your changes. See Changing File Permissions for more information
Make sure you've the correct permissions to edit the files in your FTP or File manager in Cpanel. You don't have any permissions to edit the required files. Let me explain what the File permission is and how to enable it.
What are file permissions?
This is a method of administering access rights to certain files of your site. There are 3 types of permissions, read, write, and execute. Each of these types can be defined per a certain user group. These include owner permissions, group permissions, and public permissions. Some host’s security settings do not have the ideal WordPress permissions set by default, you’ll have to add this yourself. You don’t need to worry about all these technical details. All you need to remember is the number: 666.
Changing file permissions in FTP
This is probably the quickest way of changing the file permissions for all of your template files in one swift command. Open up your favorite FTP client, navigate to your template directory (with style.css, index.php, etc.) and select all .php and .css files. Do not select images or subdirectories.
You can press CTRL + A to select them all, and click while holding CTRL to deselect items like images. After selecting the File Attributes option from the menu, you can change all the permissions to 666. You’ll notice the the group and public write permissions will automatically checked off.
After pressing OK all the permissions to the files you selected should be changed to -rw-rw-rw-. You should now be able to edit them via the theme editor.
Changing permissions in cPanel
You can also do this in cPanel, although not in bulk (for the version of cPanel I’m using anyway). Open up the file manager, navigate to the template directory (similar to FTP) and click on the file you want to change permissions for.
Change each one to 666, as before. This could be useful if you don’t have access to an FTP client, or just want to selectively make files writable.
You may see different sources telling you to set everything to 777, which gives everybody full permissions. I wouldn’t recommend this. Although it would work, it may open up security holes on your site. The 666 permissions are just enough for the text files you’ll be editing.
I have fixed this by a command :-
sudo chmod -R 777 "filepath"
I implemented a feature that allow users to upload files. Everything was working perfectly on my machine. After we deploy it, I got the following error:
Access to the path '\...\VendorDocuments\TempFolder\2585' is denied.
I've added EveryOne in the list of the object that have all the permissions to the VendorDocument folder. It worked.
Now I'd like to know how to setup the permissions to take into account the security aspects.
vendorDocuments is the main folder.
Inside vendorDocuments there is another folder called TempFolder
When user selects a file, the file is automatically uploaded to a TempFolder/UserId
If the user decides to cancel the operation, the file inside the TempFolder is deleted.
If the user decides to proceed, the file will be moved from the TempFolder/UserId to a folder belonging to the vendor still inside vendorDocuments.
VendorDocuments => TempFolder => TempFolder => UserId (file inside)
VendorDocuments => VendorName => DocumentId (file inside)
So in my opinion, there are 2 problems;
How to setup the permission on the highest level, i.e. vendorDocuments folder.
Do I need to setup permission as well for every vendor folder, i.e. where files belonging to a given vendor will be saved. There reason I asking this question is because I read that it's better to setup manually permission on folder. However, in this case, vendor's own folder will be created on the fly, i.e. the first time a user belonging to that vendor upload a file.
Sorry to ask a long question. This is the first time I'm working with permissions.
We take care of our permission like this by assigning an application pool identity to the application itself. This allows you to give the applications account the permissions it needs to write files to their destination. We are using IIS and I can see that depending on your version of IIS the process is slightly different. IIS instructions: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
I get this problem now and then, where I use an FTP account given to me by the host and use them in Wordpress FTP. But for some reason when updating themes for example, the new theme gets created under apache/apache and not user/psacln user name/group. So at that point I can't delete or do anything with those files as I am under psacln group.
I would like to find out more about why this may happen to avoid this problem - any suggestions are welcome!
Thanks in advance.
When you upload files via the wordpess admin page (like themes) the httpd process running as the apache user is actually creating them on your system--hence why they are owned by the apache user. I suggest this options to work around this:
Add yourself and apache to a new group called 'wordpress'
Use to change group ownership of your wordpress to the new group
Use set the sgid permission bit and the group write permission to all directories in the wordpress docroot.
The setting of the sgid bit will make all files added to a directory be the same group owner.
Assuming you've added yourself and apache to the same group, here's the linux commands to setup the directories to ensure files get created writable to all in the wordpress group:
chown -R :wordpress /path/to/wordpress/docroot/
chmod -R g+w /path/to/wordpress/docroot/
find /path/to/wordpress/docroot/ -type d -print | while read i; do SAVEIFS=$IFS; IFS=$(echo -en "\n\b");chmod g+s $i; IFS=$SAVEIFS; done
Additional thing that may be needed:
If you see apache creating files with group permissions without write, you may need to change the default umask for the apache user for creation of new files. By default it should be owner and group write allowed, but I know some accounts (like root user) have the default umask set to be group read only.
because apache's worker children run under apache's userid, and a "common user" on a unix system cannot make files be owned by some OTHER user. Only the root account can "give away" ownership.
Why? It'd be trivial for a normal user to make a file owned by root, or owned by another user. If a given system was running with user quotas, this would allow a user to completely subvert the quotas, or deny someone else access by "giving" them a bunch of huge files and exceeding that user's quota.
If you need access to those files, regardless of the unix ownership, you could look into using POSIX acls, which exist above/beyond the unix permissions.
I recently switched my development machine from Windows XP to Windows 7 and since that switch, I have a problem with files permissions when I do operations with Tortoise SVN.
Example:
I Have two ASP.NET website set on my local IIS. Beta and Devlo. Beta is a check out of the branch I'm working on and Devlo is a check out of the Trunk.
I made some change on the Beta website and Check it in.
Then I made a merge to reintegrate the branch in the truck on the Devlo website, but I got this error when I test it :
Parser Error
Description: An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error details
and modify your source file appropriately.
Parser Error Message: Access to the path 'C:\[...]' is denied.
After investigation, I discovered that every file that was modified by the Tortoise SVN merge lost theirs file permission (Read, Read & Execute) for the users IUSE and IIS_IUSRS.
I could manually put them back, but this happen every time I perform an operation of this kind. Is there a way to keep those permissions unchanged by the SVN operation?
Update
Before the Merge, the file was inheriting is permission from the parent folder (has it's supposed to do.)
But not after the merge :
The original file (in the beta folder) was inheriting is permission from the parent folder.
Why the TortoiseSVN (explicitly?) block permission inheritance?
I had the same issue and fixed it with the help of this SO answer: https://stackoverflow.com/a/8993163/361831
The answer mentions that updated files are copied to a .svn/tmp directory which is located in the top level of your working copy (as of tortoiseSVN 1.7). This top level dir didn't have the IIS permissions so I guess they weren't inheriting during the copy. So I just set the IIS permissions to that top level dir and set to inherit, and that fixed the issue.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)
ANSWER: Locate your .svn directory for that project and fix the permissions with permissions needed by your project.
You should be able to set these permissions on the folder that contains the files and then let the files inherit these permissions, instead of explicitly setting the permissions on the files themselves.
TortoiseSVN may delete and create files instead of renaming. When a new file is created this way it will not have the original permissions, but it will inherit permissions from its container.
See also: Explicit vs. Inherited Permissions
Each permission that exists can be assigned one of two ways:
explicitly or by inheritance. For this reason, permissions are
referred to as explicit permissions and inherited permissions.
Explicit permissions are permissions that are set by default when the object is created, or by user action.
Inherited permissions are permissions that are given to an object because it is a child of a parent object.
Similar to the way rights are managed for groups of users, permissions
are best managed for containers of objects. Objects within the
container inherit all the access permissions in that container.
See also: TortoiseSVN - Deleting, Moving and Renaming
Since renames and moves are done as a delete followed by an add...
I had the same problem on both my Win7 64bit machines. I would check in code on one, go to the other, do a Tortoise SVN Update, and have to reset the permissions on the folder to let the parent folder's permissions propagate downwards.
I finally found this article, tried it, and two weeks later it seems to be holding up.
Open the Registry Editor (click Start > Run, type regedit, then press ENTER).
Locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
With the key selected, on the Edit menu, click Add Value, and then add the following registry value:
Value name: ForceCopyAclwithFile
Data type: DWORD
Value data: 1
Exit the Registry Editor.
http://kb.globalscape.com/KnowledgebaseArticle10473.aspx
Does the "execute" bit also mean "deletion" permissions, or do I need "write" permissions for that?
To remove a directory, the parent of that directory must be writable by the effective user. The write and execute flags of the directory being removed do not matter.
Additionally, one cannot remove a directory if it is not empty. Often a user will use the rm -r command to remove a non-empty directory tree recursively by first removing all its contents. If the user does not have write permission to the subdirectories, he/she cannot empty their contents first.
No, the 'execute' bit is used by directories to determine whether a 'user' can view the files listed in the directory. In regards to deletion the relevant bit is the 'write' permission bit of the parent directory.