how to set file permission to directory that directory permission is assign automatically to files under that directory when we create new file into the directory
please any one let me know who know the answer
I think you're asking about how to make files inherit permissions from their parent directory. I will assume you're using GNU/Linux (you've added the redhat and ubuntu tags), in which case this can be done from the terminal by assigning group ownership to the directory and getting the children (files) to inherit from there.
To do this:
Recursively set the directory permissions:
chmod -R <octal permission code> /path/to/parent_dir
Recursively change ownership of directory:
chown -R <you>:<yourgroup> /path/to/parent_dir
Set inheritance of group ownership with setgid bit:
chmod g+s /path/to/parent
Note that the setgid bit means that executables will run with the same permissions as if they'd been run by the group: see here. If you don't understand the permissions, the easiest way to find the chmod octal code (for a beginner) is with a calculator. This is also a duplicate and probably doesn't belong on here, but since I can't see it mentioned on stackoverflow (it is on the Ubuntu StackExchange and Super User StackExchange) I'll answer here :)
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.
Why can the ls command of Ubuntu list the files of a directory with no execution permission set ?
The Test directory has read and write permissions set but no execution permission set. I understand that the x attribute of the directory specify whether the directory can be accessed, and if it is not set then it doesn't matter whether r or w is set (please correct me if I'm wrong).
The cd and cat commands works as expected, i.e. that cannot do their job, since they cannot access the directory.
Having +r but not +x on a directory allows reading its contents, but not making it the current directory. Conversely, having +x on a directory but not +r will allow you to make it your current directory but not list it.
In other words, on a directory:
r: The read bit allows you to read the contents of that directory
w: The write bit allows you to create, rename and delete files
x: The execute bit allows you to chdir into that directory
Edit:
Apologies, after re-reading the original post, I have a better understanding of the question. The files can be listed even though there is no execute permission because you have read permission on the directory. The x bit controls access to the inode, which contains the file metadata such as permissions info. This is why the files can be listed, but no permission data is available.
https://askubuntu.com/questions/83788/accessing-files-in-a-directory-without-x-permission
See also:
https://unix.stackexchange.com/questions/21251/how-do-directory-permissions-in-linux-work
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.