9

I've stumbled upon surprising (for me) permission behavior on FreeBSD. Let's say I'm operating as non-root user. I create a file, set its permission on read-only and then try to write into it:

$ touch f
$ chmod 400 f
$ ls -l f
-r--------  1 user  wheel  f
$ echo a >> t
t: Permission denied.

So far so good. Now I do the same as root and it writes into the file:

# ls -l f2
-r--------  1 root  wheel  f2
# echo a >> f2
# echo $?
0

Is it a bug or intended behavior? Can I safely assume that this would work so on any Unix & Linux?

  • Any user with CAP_DAC_OVERRIDE can do this. On nearly all Linux systems this means root can do this so it's intentional. Can't speak for the FreeBSD part but I'd imagine they have a similar setup. – Bratchley Aug 16 '16 at 19:52
  • 1
    The reason root needs to ALWAYS be able to write to a file is because on traditional unix filesystems (ext4, zfs etc.) file permissions are part of the file. So if root cannot write to a file then NOBODY can make read-only file writable again because chmod cannot write to the file. – slebetman Aug 17 '16 at 2:59
  • 1
    @slebetman You don't need to have write access to a file to update the permissions. Just try touch somefile; chmod 0000 somefile; chmod 0644 somefile as a normal user. – immibis Aug 17 '16 at 7:43
  • @immibis: That you own. Root needs to be able to change permissions on files that it doesn't own – slebetman Aug 17 '16 at 7:47
  • @slebetman Yeah... but you were talking about changing permissions on files you can't write to, not about changing permissions on file you don't own. – immibis Aug 17 '16 at 7:52
13

It's normal for root to be able to override permissions in this manner.

Another example is root being able to read a file with no read access:

$ echo hello > tst
$ chmod 0 tst
$ ls -l tst
---------- 1 sweh sweh 6 Aug 16 15:46 tst
$ cat tst
cat: tst: Permission denied
$ sudo cat tst
hello

Some systems have the concept of immutable files. eg on FreeBSD:

# ls -l tst
-rw-r--r--  1 sweh  sweh  6 Aug 16 15:50 tst
# chflags simmutable tst
# echo there >> tst
tst: Operation not permitted.

Now even root can't write to the file. But, of course, root can remove the flag:

# chflags nosimmutable tst
# echo there >> tst
# cat tst
hello
there

With FreeBSD you can go a step further and set a kernel flag to prevent root from removing the flag:

# chflags simmutable tst
# sysctl kern.securelevel=1
kern.securelevel: -1 -> 1
# chflags nosimmutable tst
chflags: tst: Operation not permitted

Now no one, not even root can change this file.

(The system needs rebooting to reduce the securelevel).

  • How is requiring reboot an effective security measure? Also, if root is root and can do anything, why even bother trying to prevent root from doing what root wants? – cat Aug 17 '16 at 3:21
  • 1
    On a secure system, root is not God-like. FreeBSD securelevel is a small attempt to make root less God like. Securelevel can be set to default to 1 in system config so it stays active even after a reboot. So then it'd need console access and single user mode and that's very tamper evident. There's a whole essay around Unix security that's far too much for a SE comment field, but we're trying to move on from a 'root has all access' model into something more nuanced. We try to enforce where possible (eg securelevel) and detect where not (reboot evidence, audit trails). – Stephen Harris Aug 17 '16 at 3:55
  • 4
    FWIW, in Linux chattr +i tst sets immutable attribute. – Ruslan Aug 17 '16 at 5:10
3

Yes, this is very normal. root has no limits on read/write (with very little exception), because he is the root.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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