LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This 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


Reply
  Search this Thread
Old 01-07-2015, 02:25 PM   #1
ss32
Member
 
Registered: Apr 2013
Distribution: Ubuntu, Linux Mint, RHEL, CentOS
Posts: 43

Rep: Reputation: Disabled
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?
 
Old 01-07-2015, 02:35 PM   #2
vincix
Member
 
Registered: Feb 2011
Distribution: Centos 6.7, 7
Posts: 676

Rep: Reputation: 69
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)

Last edited by vincix; 01-07-2015 at 02:41 PM.
 
Old 01-07-2015, 02:37 PM   #3
ss32
Member
 
Registered: Apr 2013
Distribution: Ubuntu, Linux Mint, RHEL, CentOS
Posts: 43

Original Poster
Rep: Reputation: Disabled
I need this to be system wide for all users. Could I add that to /etc/profile?
 
Old 01-07-2015, 02:53 PM   #4
vincix
Member
 
Registered: Feb 2011
Distribution: Centos 6.7, 7
Posts: 676

Rep: Reputation: 69
Quote:
Originally Posted by ss32 View Post
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.

Last edited by vincix; 01-07-2015 at 03:01 PM.
 
Old 01-07-2015, 03:52 PM   #5
vincix
Member
 
Registered: Feb 2011
Distribution: Centos 6.7, 7
Posts: 676

Rep: Reputation: 69
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

Last edited by vincix; 01-07-2015 at 03:53 PM.
 
Old 01-08-2015, 09:23 AM   #6
veerain
Senior Member
 
Registered: Mar 2005
Location: Earth bound to Helios
Distribution: Custom
Posts: 2,524

Rep: Reputation: 319Reputation: 319Reputation: 319Reputation: 319
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.
 
Old 01-08-2015, 06:06 PM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,696

Rep: Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261
Quote:
Originally Posted by vincix View Post
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.

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
As always, try it out.

Last edited by jpollard; 01-08-2015 at 06:07 PM.
 
Old 01-09-2015, 03:29 PM   #8
vincix
Member
 
Registered: Feb 2011
Distribution: Centos 6.7, 7
Posts: 676

Rep: Reputation: 69
@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.
 
Old 01-09-2015, 04:47 PM   #9
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,696

Rep: Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261Reputation: 1261
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.
 
Old 01-09-2015, 06:06 PM   #10
ss32
Member
 
Registered: Apr 2013
Distribution: Ubuntu, Linux Mint, RHEL, CentOS
Posts: 43

Original Poster
Rep: Reputation: Disabled
For whatever reason adding the proper umask to /etc/profile didn't work but adding it to /etc/basrc did.
 
Old 01-22-2015, 11:18 AM   #11
ss32
Member
 
Registered: Apr 2013
Distribution: Ubuntu, Linux Mint, RHEL, CentOS
Posts: 43

Original Poster
Rep: Reputation: Disabled
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.

Last edited by ss32; 01-22-2015 at 11:24 AM.
 
Old 01-22-2015, 11:30 AM   #12
ss32
Member
 
Registered: Apr 2013
Distribution: Ubuntu, Linux Mint, RHEL, CentOS
Posts: 43

Original Poster
Rep: Reputation: Disabled
Fixed it with

Code:
chmod u-s /DIR
 
Old 01-23-2015, 10:35 AM   #13
vincix
Member
 
Registered: Feb 2011
Distribution: Centos 6.7, 7
Posts: 676

Rep: Reputation: 69
Quote:
Originally Posted by ss32 View Post
Fixed it with

Code:
chmod u-s /DIR
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Setting separate default file and directory permissions acunacha Linux - Server 2 11-06-2012 04:47 PM
[SOLVED] Default permissions of newly created directories fakie_flip Linux - Software 4 10-31-2012 06:22 AM
[SOLVED] Setting default permissions for new files under a directory sabresong Linux - Newbie 3 07-02-2012 07:16 PM
ACLs, default permissions, directories and files hydraMax Linux - Security 11 01-12-2011 06:19 AM
Setting permissions that include sub-directories AlcoholicDoc Linux - Newbie 2 12-19-2005 10:33 AM


All times are GMT -5. The time now is 04:48 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration