Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Development Tools Console Foundations Users and Permissions File Permissions

Why wont adding permissions for everyone always add a permission for 'others'?

I was interested to find out if the command 'chmod +r hello.txt' would still work if any of the user/group/others already have the 'read' permission

If no users have the 'r' permission then 'chmod +r hello.txt' will add that permission for the user, group and others.

However if the 'user' already has the 'read' permission then 'chmod +r hello.txt' will add the read permission for the group but not for 'others'.

I found this was also the case with the 'w' and 'x' permissions.

This is an interesting inconsistency and I wonder if anyone knows why this is the case?

For example perhaps the idea is that if only 'user' of 'group' has a permission then the assumption is that someone has previously chosen not to grant permission to everyone.

On this basis the 'chmod +r' command will extend the permission to the group but not 'others' as a means of preventing accidental 'oversharing' of permissions?

4 Answers

Oh, I know what's up! We can blame the umask.

The umask on the console foundation systems (which are Ubuntu) is different than where I tested (OS X and CentOS). Here's an example for a Console Foundations console:

# with the default umask

treehouse ~ $ umask                                                             
0002                                                                            
treehouse ~ $ touch test.txt                                                                                                                        
treehouse ~ $ ls -l test.txt                                                    
-rw-rw-r-- 1 treehouse treehouse 0 Oct 30 22:52 test.txt                        
treehouse ~ $ chmod 644 test.txt                                                
treehouse ~ $ ls -l test.txt                                                    
-rw-r--r-- 1 treehouse treehouse 0 Oct 30 22:52 test.txt                        
treehouse ~ $ chmod +w test.txt                                                 
treehouse ~ $ ls -l test.txt                                                    
-rw-rw-r-- 1 treehouse treehouse 0 Oct 30 22:52 test.txt 

# and with another common umask

treehouse ~ $ umask 0022                                    
treehouse ~ $ umask                                                             
0022                                                                            
treehouse ~ $ chmod 644 test.txt                                                
treehouse ~ $ ls -l test.txt                                                    
-rw-r--r-- 1 treehouse treehouse 0 Oct 30 22:52 test.txt                        
treehouse ~ $ chmod +w test.txt                                                 
treehouse ~ $ ls -l test.txt                                                    
-rw-r--r-- 1 treehouse treehouse 0 Oct 30 22:52 test.txt                   

So as you can see the umask influences how chmod +whateva somefile is interpreted. So I suppose the moral here is that it's best to either use octal or do the more explicit symbolic notion (chmod o+w somefile) if the vaguer syntax is causing you an issue.

Edit: Great question by the way.

The POSIX standard clarifies this.

The who symbols u, g, and o shall specify the user, group, and other parts of the file mode bits, respectively. A who consisting of the symbol a shall be equivalent to ugo. […] If who is not specified, the file mode bits represented by perm for the owner, group, and other permissions, except for those with corresponding bits in the file mode creation mask of the invoking process, shall be set.

The GNU manual puts this in plainer language.

A combination of the letters ugoa controls which users' access to the file will be changed: the user who owns it (u), other users in the file's group (g), other users not in the file's group (o), or all users (a). If none of these are given, the effect is as if (a) were given, but bits that are set in the umask are not affected.

a controls all users unconditionally whereas none observes the umask. Therefore, the explicit a symbol as in chmod a+w hello.txt should do the trick.

I think the moral here is to read the manual man 1 chmod.

chmod +r somefile will add read permission for the user, group, and all users by default.

To illustrate, if the file owner and group already have read permsissions:

$ chmod 640 test.txt

$ ls -l test.txt
-rw-r-----  1 nate  staff  0 Oct 30 13:46 test.txt

$ chmod +r test.txt

$ ls -l test.txt
-rw-r--r--  1 nate  staff  0 Oct 30 13:46 test.txt

And if only the owner has read, +r still gives read to both the group and all users:

$ chmod 600 test.txt

$ ls -l test.txt
-rw-------  1 nate  staff  0 Oct 30 13:46 test.txt

$ chmod +r test.txt

$ ls -l test.txt
-rw-r--r--  1 nate  staff  0 Oct 30 13:46 test.txt

Is that different from your experience? I tried both on OS X and CentOS and had the same outcome.

In general, what I find most useful is to specify file permissions in octal. It's a little harder to wrap your head around at first, but this Wikipedia article describes both the numeric and symbolic permissions notations well (see the 'Notation of traditional Unix permissions' section).

Hi Nate,

Thanks for your reply and for providing the example. It does make sense that the command would operate consistently and simply add the permission for the user, group and all others.

On this basis I think I may be experiencing some kind of a bug or unusual configuration in the console provided on Treehouse.

Here is a screenshot from my Treehouse console:

console screenshot

As you can see the command 'chmod +w hello.txt' doesn't add the 'write' permission to all users. As you say using octal notation to specify permissions is clearly a lot simpler and faster (and I watched that video shortly after posting this question!).

Nevertheless I thought this was an interesting anomaly. Is this a bug or perhaps a custom configuration of some kind?

Thanks for the detailed answer Nate, much appreciated.

As an aside I don't know if there is a plan for a more comprehensive console course but I think that would be really useful.

I'd like to see us do that too!