Setting default directory permissions for new directories
 

This should be an easy fix and I'm at a loss. I have a directory with 777 permissions on it and currently any directories created inside it default to

drwx--S---

I need to remove the sticky bit and also set any new directory to be readable by group X. How can I do this?

Edit /home/<your_user>/.bashrc (or /root/.bashrc) and write the following line:
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:
(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.

I think this would help a bit in understanding what this does, but you need to practise yourself. This is what I've been doing and it's becoming clearer: http://computernetworkingnotes.com/m...ticky-bit.html

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.

Hope I can help.
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.
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
As always, try it out.

@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.

For whatever reason adding the proper umask to /etc/profile didn't work but adding it to /etc/basrc did.

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:

/etc/profiles
/etc/bashrc
/etc/csh.cshrc
/etc/csh.login
/etc/profiles.def

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.

Fixed it with

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.