13

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?

6
  • 1
    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
    Commented Aug 16, 2016 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
    Commented Aug 17, 2016 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. Commented Aug 17, 2016 at 7:43
  • @immibis: That you own. Root needs to be able to change permissions on files that it doesn't own
    – slebetman
    Commented Aug 17, 2016 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. Commented Aug 17, 2016 at 7:52

2 Answers 2

15

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).

3
  • 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
    Commented Aug 17, 2016 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). Commented Aug 17, 2016 at 3:55
  • 4
    FWIW, in Linux chattr +i tst sets immutable attribute.
    – Ruslan
    Commented Aug 17, 2016 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .