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?

Improve this question
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. 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. 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 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

Reset to default
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).

Improve this answer
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? 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. 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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.