<<< Back to Tips Index

4 Aug 2015 (being updated August 2017)

chmod 777

Why Not chmod 777?

Because.

But seriously, what are you trying to achieve? It is probably due to a misunderstanding of the Unix/Linux filesystem permissions model. The question is common (hence this page), but the answer is always the same: If you assess what your requirements are, you are very likely to find that the existing permissions model will work for you, as it has done for many different projects over the decades. The chances that your project is significantly different from all other Unix/Linux projects is very low.

Most Unix and Linux systems generally allow appropriate access to files; /bin/ls can be executed by anybody to list files; your /home/USERNAME/.bashrc is readable by you, but your /home/USERNAME is typically accessible only to yourself, and as a result of that, anything under that location (including your .bashrc) is also unavailable to other users of the system.

This is a deliberate part of the design. It has been in use for over 40 years (at time of writing, in 2017), and it has worked very well for very many successful projects, and although it is quite a simple system, there are a few nuanced ways in which it can be used to suit your particular needs, if they are particularly specialised.

Group Membership

The easist way to approch sharing files between users, is to put them in a common group. If you are in the group, you can access the files.

SetGID Bit

The "SetGID Bit" on a directory means that any files created in that directory will be owned by the group that owns the directory, regardless of who created them. It is marked as an "s" in place of the "x" where the Group permissions go: drwxr-sr-x. It is set by the command: "chmod g+s <directory-name>".

Invest in your career. Buy my Shell Scripting Tutorial today:

 

Steve's Bourne / Bash shell scripting tips
Share on Twitter Share on Facebook Share on LinkedIn Share on Identi.ca Share on StumbleUpon