My folder at:
/usr/local/www/.ext_env_vars
has a bunch of files in it that my app needs to read. The user is 'webapp'
So, I changed the perms like so:
chmod -R 400 .ext_env_vars
chown -R webapp.webapp .ext_env_vars
The application can't read these. However, when I chmod 777, they are read by the app. So, it isn't that I have a path problem. Seems to be permissions only.
So, what would I have to do to the permissions to make webapp be able to read those files in the .ext_env_vars folder?
Thanks
Eric
A directory needs to be "executable" to access it. Try:
chmod 500 .ext_env_vars
Related
I need some help about permissions on Linux. I know having world writable file can be dangerous and many people recommend to not have world writable file.
In order to "protect" my Linux, i searched for every world writable file using find / -perm -0002 -type f. Thanks to this command, I found a world writable file under my /root/a_directory/. As my /root directory is 700, other user cant edit the world writable file.
So my question is, what is the risk if I have world writable file under a directory which can't be access by other users ?
Am i safe if /directory1/world_writable_file.sh is 777 and /directory1/ is 700. Is there no risk with this situation ?
Directory permissions behave quite differently from file permissions.
Since the directory doesn't allow other (non-root and non-group) users any operation (read/write/execute) on the directory, they can't even enumerate the files inside this directory, so they sure can't access them.
Here is a practical example:
user#host$ sudo su
root#host$ mkdir testdir
root#host$ printf '#!/bin/bash\necho test" > testdir/testfile
root#host$ chmod 0777 testdir/testfile
root#host$ chmod 0700 testdir
root#host$ exit
user#host$ ./testdir/testfile
-bash: ./testdir/testfile: Permission denied
user#host$ ls testdir
ls: cannot open directory 'testdir': Permission denied
However, this is NOT a good practice in handling sensitive files.
It is very easy to misconfigure file permissions, so you should never rely on having a secure directory.
If someone accidentally changes the directory's permission to 0701 (others can execute), which seems like a fairly negligible change, everyone will be able to execute, read and write any file with 0777 permissions if they know its exact path.
Moreover, the scenario you described can happen only if:
A. The permissions on the directory are changed after the files are already there. In this case, you should simply use chmod -R o-rwx to remove permissions for other users.
B. The directory owner created the file after the directory was already configured, and then added permissions using chmod o+wx or something similar. Since new files created in a directory with 0700 permissions mask, have a default mask of 0644, and the only user that can access the directory is the owner, there is no other way. In this case, simply refrain from doing so.
Anyway, if you are interested in reading and understanding more about UIDs in Unix systems in general and Linux in specific, I wrote a comprehensive guide on the subject.
I have a quick question. I've been trying to upload my website to blue-host, but every time I try, it says that parent path doesn't exist, is there a way I can change the parent path so the uploads work
Thx,
willmonferno
This is likely due to file permissions, you don't have write access, try updating file owner or file permissions.
I'm guessing you on some type of linux system, so you either need a chown (change owner) shell command or a chmod command (change file permissions) on the parent folder
try:
sudo chmod -R 777 {YOUR_PARENT_FOLDER}
This will recursively change this and all other files and folders below it in the file tree to allow everything. I would change it once you're in a production environment.
Assuming that I have this directory structure:
/tmp/mysockets/appname/
What are the security drawbacks to doing chmod 777 on /tmp/mysockets/?
Could another user delete or mess with the reference to the appname/ directory?
What I want to do is allow other users to add their own directories to /tmp/mysockets/ but I don't want to allow them to rename it or delete files/subdirectories which are already inside it (owned by another user).
I think you are looking for sticky bit, thats will do what you want. With permissions 777 you grant read/write permissions to everybody therefore the files can be removed/renamed
A sticky bit is a permission bit that is set on a directory that allows only the owner of the file within that directory or the root user to delete or rename the file. No other user has the needed privileges to delete the file created by some other user.
To set a sticky bit use following
chmod o+t /tmp/mysockets/
or e.g.
chmod 1757 /tmp/mysockets/
I would like to know what is the best, correct and recommended way of doing chown and chmod to website files and folders.
I recently started working on linux and I have been doing it in the site root directory like the following:
sudo chown www-data:www-data -R ./
sudo chmod 775 -R ./
I know it is not the best way. There is a protected folder which should not be accessible with browsers and should not be writable, so I did the following to protected folder:
sudo chown root:root -R protected/
sudo chmod 755 -R protected/
Is it correct? If anything can be improved please let me know.
Read your command again. What you are saying is "make everything executable" below these directories. Does an HTML or gif to be executable? I don't think so.
Regarding a directory which should not be writable by the webserver. Think of what you want to do. You want to revoke the right to write a directory from the webserver and the webserver group (and everybody else anyway). So it would translate to chmod -w theDir. What you did is to tell the system "I want root to make changes to that directory which shall be readable by everybody and the root group". I highly doubt that.
So I would suggest having the directory owned by a webserver user with only minimal read access, it should belong to a group (of users, that is) which is allowed to do the necessary of the modification. The webserver does not belong to that group, as you want the outside world to be prevented from making modifications. Another option would be to hand over all the directories to root and to the editor group and modify what the webserver can do via the "others" permission group. But what to use heavily depends on your environment.
Edit:
In general, the "least rights" policy is considered good practice: give away as few rights as possible to get the job done. This means read access to static files and depending on your environment php files, read and execute rights for cgi executables and read and execute rights for directories. Execute rights for directories allow you to enter and read it. No directory in the document root should be writable by the webserver ever. It is a security risk, even though some developers of bigger CMS do not seem to care to much about that. For temporary folders I would set the user and groups to nobody:nogroup and set the sticky bit for both user and groups.
When cding into one of my directories called openfire the following error is returned:
bash: cd: openfire: Permission denied
Is there any way around this?
#user812954's answer was quite helpful, except I had to do this this in two steps:
sudo su
cd directory
Then, to exit out of "super user" mode, just type exit.
Enter super user mode, and cd into the directory that you are not permissioned to go into. Sudo requires administrator password.
sudo su
cd directory
If it is a directory you own, grant yourself access to it:
chmod u+rx,go-w openfire
That grants you permission to use the directory and the files in it (x) and to list the files that are in it (r); it also denies group and others write permission on the directory, which is usually correct (though sometimes you may want to allow group to create files in your directory - but consider using the sticky bit on the directory if you do).
If it is someone else's directory, you'll probably need some help from the owner to change the permissions so that you can access it (or you'll need help from root to change the permissions for you).
chmod +x openfire worked for me. It adds execution permission to the openfire folder.
Alternatively, you can do:
sudo -s
cd directory
You've got several options:
Use a different user account, one with execute permissions on that directory.
Change the permissions on the directory to allow your user account execute permissions.
Either use chmod(1) to change the permissions or
Use the setfacl(1) command to add an access control list entry for your user account. (This also requires mounting the filesystem with the acl option; see mount(8) and fstab(5) for details on the mount parameter.)
It's impossible to suggest the correct approach without knowing more about the problem; why are the directory permissions set the way they are? Why do you need access to that directory?
I know this post is old, but what i had to do in the case of the above answers on Linux machine was:
sudo chmod +x directory
Unless you have sudo permissions to change it or its in your own usergroup/account you will not be able to get into it.
Check out man chmod in the terminal for more information about changing permissions of a directory.