Everyone who uses Linux (or some Unix) knows the normal file permissions that are administered with chmod, at least to some extent.
It is worth noting, what permissions of a file and the underlying directory mean.
In order to read the file, one needs read rights for the file and also read and executable rights for the directory in which the file is located and all super-directories.
Having the write right for the file means being able to change its contents. Which could mean deleting all content leaving a zero byte file.
But the right to delete a file requires write access to its directory, because it changes the contents of the directory. Same with creating files. rm actually checks if you have write access to the file as well, unless you use rm -f, which is just enforced by rm, not by the system.
Now there is another bit that comes in. ACL-rights, which can override the settings of the normal permissions and for example get specific users read or write access. These are read using getfacl and changed using setfacl. I think it would be desirable that ls had an option to show these ACL-rights as well, but it does not yet have that, at least not the version that I am using. What ls at least does: it shows a ‚+‘ after the normal permissions string, which indicates that acl-rights are actually in use.
So, if you do file operations and observe something works or does not work, which cannot be explained by the normal file permissions, check the ACL.
Now things can get even a bit more hairy, if you mount remote directories from a file server, because now accessing them requires that your computer and the file server allow it. And the network including firewalls.
Yet another bit can come in, it is called „SELinux“. Linux supports security modules and if a security module is present, all system calls are checked against the security module and may end up with „permission denied“. AppAmor is an example and the most well know security module is SELinux. It allows fine granular permission policies what is allowed and what is not allowed. In the end we get „permission denied“ although there is no visible obstacle. You can find out if that is the case by running
sestatus
and
getenforce
Now on productive systems it may not be allowed to turn off security features just for the fun of it, because they should protect from certain attack scenarios and we must expect that these attacks happen exactly when we turn them off for a minute to check something. But of course we do have test systems and there we can try out things. If after
setenforce 0
the same command works and after
setenforce 1
it does not work, than SELinux is stopping it. Which means you have to fix your SELinux settings or file attributes which are observed by SELinux.
Links
