Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am running a small embedded system built using buildroot. I have come across this strange behaviour when trying to set up my file permissions on the target device. To illustrate what confuses me I tried the following simpler example

# cd /mydir
# touch tmp.txt
# echo "rubbish" > tmp.txt
# cat tmp.txt

# chmod 0444 .
# chmod 0444 tmp.txt
# echo "new-rubbish" > tmp.txt
# cat tmp.txt

I am really confused by this. How can I have set the file and directory to be read only and yet I am still able to modify the contents of this file? I have an executable within the same directory and when I try and execute it I get this

# chmod 0444 my_binary
# ./my_binary
-sh: ./my_binary: Permission denied

which behaves as I would expect it to. Clearly I have some fundamental misunderstanding of how the file access model works on Linux. Can anyone explain why I am able to write to the file that I have set to be read only?

share|improve this question
up vote 3 down vote accepted

As you seem to be doing this as root that explains you have rights to write in the directory. root can also append to the file even if it permissions are -r--r--r--.


echo "new-rubbish" > tmp.txt

does truncate the file (as JoelDavis pointed out), so it does not remove it and write it again (when using bash).

share|improve this answer
Thanks for this answer. I realise now that chmod is not sufficient for my requirements and I need to use chattr +i on my files. Thanks again – mathematician1975 Jun 6 '13 at 10:40
@Anthon Minor point that doesn't affect the validity of your answer and I hate to be contrarian but bash at least appears to open the file with O_TRUNC. I linked a demonstration of the idea, basically neither the inode number or the inode's crtime changes, and further greps on the strace output (not shown) don't show any unlink operation. It's probably more likely that the OP is noticing root's implicit possession of CAP_DAC_OVERRIDE on almost all GNU/Linux implementations. – Bratchley Jun 6 '13 at 11:13
@JoelDavis Thanks for pointing that out. I thought I remembered that things were that way as I looked at this in more detail a long time ago. But that was not with bash (I cannot remember if it was bourne or csh), on a PDP-11. So it could as easily be that my memory of things are wrong. – Anthon Jun 6 '13 at 11:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.