[SOLVED] Setting default directory permissions for new directories
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Edit /home/<your_user>/.bashrc (or /root/.bashrc) and write the following line:
Quote:
umask 0022
This is the default umask. The sticky bit is disabled and you've got 644 for files and 755 for directories by default.
Ignore what I've just said. I was referring to something else.
Ok, so for a directory you need to change those particular permissions:
Quote:
# chmod 0750 /path/to/directory
(the first 0 removes the sticky bit, 7 - full access to owner and 5 read and execute for the directory. You need execute to have recursive access to it, so basically you need execute to be able to read the files and directories under that directory)
I need this to be system wide for all users. Could I add that to /etc/profile?
Yes, my second answer was partially wrong anyway, because the default permissions on newly created files/directories under that directory have nothing to do with the permissions on that directory, except for the sticky bit (and the other special permissions, setuid etc.)
So first of all, you need to remove the sticky bit. You can do that by running # chmod -s /path/to/dir
Then write what is the default umask for most linux systems (umask 0022) Yes, you can modify /etc/profile or /etc/bashrc.
Just append/modify the line in one of those files. Check if there isn't already a simple umask line in either of these files.
My advice has been rather bad. It would be nice if someone more knowledgeable would help.
The thing is (from what I've read) you need an execute permission for the group on that directory in order for all the files dropped into that folder to belong to the X group. This is what "S" means, that setgid (which is NOT sticky bit, which in turn, is represented by +t) is not going to apply (so the newly created files won't belong to that group) because the group permission for the main directory doesn't have an execute permission.
Therefore you need to change the directory permissions (in my opinion) to 5777.
So change the directory's group to "X": # chgrp X dir
Then all newly created files will be belong to group X and, very importantly, the owners of those files won't be able to delete others' files because of sticky bit (t) on the main directory. Hope that helps.
You can put umask in /etc/profile. Then any prog that uses bash or sh shell will set correct permissions. Otherwise you can put them in /etc/login.defs file also.
My advice has been rather bad. It would be nice if someone more knowledgeable would help.
Hope I can help.
Quote:
The thing is (from what I've read) you need an execute permission for the group on that directory in order for all the files dropped into that folder to belong to the X group.
Not exactly. On directories the "x" bit means "search". Users have to have read access ("r") to be able to list the file names (just the names, nothing else), but when opening a file you need the "search" for the open to succeed (the kernel searches for the file for the user to have access). It is a bit confusing... but it is also done to maintain consistency with most access to files.
Quote:
This is what "S" means, that setgid (which is NOT sticky bit, which in turn, is represented by +t) is not going to apply (so the newly created files won't belong to that group) because the group permission for the main directory doesn't have an execute permission.
Therefore you need to change the directory permissions (in my opinion) to 5777.
Well, there are three shown values "x" if the file/directory has the x bit set, S if it is setuid or setgid) but NOT executable, "s" if it is setuid AND executable (or search). On directories the set GID flag is used to cause files created within the directory to be given the same group ownership as the directory it is being created in. setuid on directories is ignored on linux.
As for the sticky bit: T if the sticky bit is set AND the file is NOT a directory, t if the sticky bit is set AND the file IS a directory. The sticky flag is used on directories to provide some security to shared directories (such as /tmp). When the sticky bit is set, users that do NOT own the file cannot delete the file. (the setuid on directories doesn't do anything on Linux - on BSD it allows files and directories created in that directory to be given the owner of the parent directory - like the setgid flag does for groups). Reference:http://en.wikipedia.org/wiki/Setuid
Quote:
So change the directory's group to "X": # chgrp X dir
Then all newly created files will be belong to group X and, very importantly, the owners of those files won't be able to delete others' files because of sticky bit (t) on the main directory. Hope that helps.
@jpollard
Yeah, when I talked about the executable permission on a directory, I meant to say that you needed that too, thinking that read is obviously implied if you want to list files in that directory or write if you want to (re)move, etc. The importance of x might not seem relevant at the beginning when you're trying to learn.
@OP
So basically you need the --x for recursive access, for the path depth. For instance, if you've got /dir1/dir2/file, and you've got only executable permission in /dir1 and full permission on /dir2, then you can do whatever you want with "file". If you remove the executable permission on /dir1, then you can't access what's beneath it at all and consequently you cannote remove, rename etc. that specific file.
The "x" on directories (without read) was used by anonymous FTP to allow files to be present, but hidden. The only way to retrieve them was to know the name. you couldn't take a directory listing to see what was there...
And that also affected directories within as well. If you knew the name of the directory, and that directory permitted read, then you were fine. but without knowing the directory name you would be out of luck.
Without the x bit, you can't get a file, even when you know its there.
The sticky bit is back. I've added "umask 022" to every file that might override it and I'm still getting 77 when I run "umask". And even when I manually change my umask to 022, when I create a directory the default permissions are drwxr-sr-x
edit: I have added a line that says "umask 022" in:
And it still defaults to 77. After adding the line in ~/.mycshrc (I'm on tsch) it defaults to 022 but I still get the sticky bit when creating a directory in a certain part of the machine, so I'm thinking it's something to do with that specific directory's permissions and the files/directories created inside of it.
Depending on the distros, basically you cannot get rid of the setuid (s) on directories except with symbolic chmod. If you Try 0755, for instance, it simply won't work. I've tried it myself, I've even opened a thread about this, but nobody has been able to give me a clear answer as to why this happens. It doesn't happen with the sticky bit (t), it only happens with setuid and setgid. For these you need to use symbolic chmod in order to disable.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.