The precise rule is: you can traverse a directory if and only if you have execute permission on it.
So for example to access dir/subdir/file
, you need execute permission on dir
and dir/subdir
, plus the permissions on file
for the type of access you want. Getting into corner cases, I'm not sure whether it's universal that you need execute permission on the current directory to access a file through a relative path (you do on Linux).
The way you access a file matters. For example, if you have execute permissions on /foo/bar
but not on /foo
, but your current directory is /foo/bar
, you can access files in /foo/bar
through a relative path but not through an absolute path. You can't change to /foo/bar
in this scenario; a more privileged process has presumably done cd /foo/bar
before going unprivileged. If a file has multiple hard links, the path you use to access it determines your access constraints.
Symbolic links change nothing. The kernel uses the access rights of the calling process to traverse them. For example, if sym
is a symbolic link to the directory dir
, you need execute permission on dir
to access sym/foo
. The permissions on the symlink itself may or may not matter depending on the OS and filesystem (some respect them, some ignore them).
Removing execute permission from the root directory effectively restricts a user to a part of the directory tree (which a more privileged process must change into). This requires access control lists to be any use. For example, if /
and /home
are off-limits to joe
(setfacl -m user:joe:0 / /home
) and /home/joe
is joe
's home directory, then joe
won't be able to access the rest of the system (including running shell scripts with /bin/sh
or dynamically linked binaries that need to access /lib
, so you'd need to go deeper for practical use, e.g. setfacl -m user:joe:0 /*; setfacl -d user:joe /bin /lib
).
Read permission on a directory gives the right to enumerate the entries. Giving execute permission without giving read permission is occasionally useful: the names of entries serve as passwords to access them. I can't think of any use in giving read or write permission to a directory without execute permission.
It appears that you have your Gmail password in the configuration file so you would want the the third number to be 0 (No permissions to Others). Ideal is 640
. You can change the ownership of the configuration file (using the command chown
) e.g. chown root:mail /etc/ssmtp/ssmtp.conf
.
You can send from the command line using sudo
or as root. Your web server user also need to be a member of group mail
. Or you can change that to root:www-data
if the user group of the web server is www-data
.
Best Answer
I will complete rahmu's and MV's answers with a technical solution. Everything that follows is valid for UNIX-like systems only.
Scroll past the chmod/chown section for an example using ACLs - a more powerful tool than UNIX file modes.
Finding your web server username
First, you will need to know the username under which your web server runs. If you are using Apache, it can be
apache
orhttpd
,www-data
, etc. On most Debian-like systems, Apache iswww-data
. For nginx, generally, it is alsowww-data
.To check it out, try:
Ensure that the username this command returns is coherent (for example, I use nginx 99% of time, but this command returns
tomcat7
, a Java web server I installed once).Giving permissions to the web server: using
chmod
andchown
Doing a
chmod
of 666 or 777 (the go-to solution for that kind of problems in bad documentations/tutorials) can magically make things work, but is insecure. Giving 666 or 777 permissions will give access to "others". So not just Apache, but alsograndmother
andnsa
(provided that those user accounts exist on your machine - but no really, please avoid doing this unless it's just for testing/troubleshooting).It is better to be more specific and give permissions to just you and Apache. Change the group of your files to give the full control on your files to the web server. To do this, change the owner recursively:
But most likely, you may want to keep full access on your files by changing the group only:
Then, do the appropriate
chmod
to give the groupwww-data
the same permissions as you. For example, if the current mode is 640 (6 for you, 4 for www-data, 0 for others, translating to -rw-r-----), set it to 660 (6 for you, 6 for www-data, 0 for others, translating to -rw-rw----). See rahmu's answer to learn more about file modes, it's an old, however elegant mechanism.To avoid manipulating arcane numbers with
chmod
, you can also use this syntax:It means "to the group (
g
), add (+
) read and write (rw
) permissions on folderyour/folder/
, recursively (-R
)".In 90% of cases, this should be enough.
My preferred method: using ACLs (Access Control List)
Sometimes the first solution is not sufficient. I will take the example of Symfony Framework that logs and caches a lot of data. So it needs write access to the appropriate folder.
And the
chmod
/chown
method may not be sufficient, when you are using in parallel the Symfony Console in CLI (under my user account) and the Web (web server user). This causes a lot of problems because Symfony is constantly modifying permissions.In this case, we will use the ACL (Access Control List), which is a more advanced way to manage permissions on many UNIX systems.
Here the commands given by the official Symfony documentation (please change
app/cache
andapp/logs
to your needs):On a system that supports
chmod +a
(ie. not Debian/Ubuntu)On a system that does not support
chmod +a
(most common)You will need the
setfacl
tool; maybe it is installed on your system by default, so trysetfacl -v
to see if the command is available.If the command is not available, and you are using Ubuntu 14.04+, you'll just have to install the tool:
Otherwise, follow your OS documentation, because you may need to change how your partition is mounted (Ubuntu documentation here).
And there we are:
I never had any problems with this method, satisfied or your money back.