Linux – removing write permission does not prevent root from writing to the file

linuxpermissionsrootunix

I just noticed on my Ubuntu machine (ext3 filesystem) that removing write permissions from a file does not keep root from writing to it.

Is this a general rule of UNIX file permissions? Or specific to Ubuntu? Or a misconfiguration on my machine?

# touch abc
# chmod ugo-w abc
# python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open('abc','w').write('AAA\n')
>>> 
# cat abc
AAA

Writing to the file fails (as expected) if I do this from my normal user account.

Is this normal behavior?
Is there a way to prevent root from accidentally writing to a file? (Preferably using normal filesystem mechanisms, not AppArmor, etc.)

Please teach me about something that I most definitely don't understand.

NOTE: I understand that root has total control over the system and can, eg, change the permissions on any file. My question is whether currently set permissions are enforced on code running as root. The idea is the root user preventing her/himself from accidentally writing to a file.

NOTE: I also understand that one should not be logged in as root for normal operations. I just noticed this behavior and am asking you about it.

Best Answer

1) This is a normal behaviour. root has rw access on all files at all times.

2) You can protect a file even from root (not deliberate action, but accidental, anyway) by using

chattr +i filename.ext

That is "change attributes add immutable". To remove the protection:

chattr -i filename.ext

have a look at man chattr for more info

Related Solutions

Linux – can not change file permission even with root

It could be an extended attribute of the filesystem you're using; us lsattr on the file to view the extended attributes, and do man chattr to see what each attribute means. If the file is set as immutable (i), you'll have to remove that attribute before you are able to delete it.

Linux – Vim can break file permissions

I can see that your current path is ~, your user's home directory. You should have write permissions to that directory.

Think of it another way - if you have read and write permissions to the directory, what's stopping you from copying the file, deleting the old one and renaming the new one with different permissions?

This is exactly what vim does!

If you run vim under strace, for example:

open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0644) = -1 EACCES (Permission denied)
lstat("testfile", {st_mode=S_IFREG|0644, st_size=10, ...}) = 0
getuid()                                = 1000
unlink("testfile")                      = 0
open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 3
write(3, "ffjidfjds\n", 10)             = 10
fsync(3)                                = 0
close(3)                                = 0
chmod("testfile", 0644)                 = 0

Based on this log, I can guess at the following process:

Some earlier permission checks (and chown attempts, etc.) are omitted for brevity.

open Attempt to open the file for writing (fail: permission denied)
lstat Check the owner of the file
getuuid Check the current user ID, to see if they match the file owner
unlink Delete the file (this is allowed because write permission on the directory)
open Create a new file with the same name
write The file contents (read earlier, I typed in some gibberish)
fsync Flush the file to disk (not really important)
close
chmod Change the new file's permissions to look like the old one - it just happens to have a new owner now.

Related Question

Linux – Not able to write to directory despite correct permission and group