If I type:

ls -l file.txt

I see that the rights for that file are equivalent to "456":

  • 4 = owner (r--)
  • 5 = group (r-x)
  • 6 = others (rw-)

Which are the rights for root in this case? Does it have 777?

Could the rights be changed so that the root will have less permissions than the owner?


I would check this page out. It talks about file permissions in depth.

But to answer your question directly, no:

The super user "root" has the ability to access any file on the system.

In your example for instance if the file is owned by say bob and the group owner was also bob, then you would see something like this:

-r--r-xrw-. 1 bob bob 8 Jan 29 18:39 test.file

The 3rd bit group the (rw) would also apply to root, as root being part of the others group. If you tried to edit that file as root you would see that you have no problem doing so.

But to test your theory even more, if the file was owned by root:

-r--r-xrw-. 1 root root 8 Jan 29 18:40 test.file

And you again went to edit the file, you would see that you still have no problem editing it.

Finally if you did the extreme:

chmod 000 test.file
ls -lh test.file
----------. 1 root root 8 Jan 29 18:41 test.file

And you went again to edit the file you would see (at least in vi/vim) "test.file" [readonly]. But you can still edit the file and force save it with :wq!.

Testing @Stéphane Chazelas claim with a shell script file:


echo "I'm alive! Thanks root!"

[root ~]# ls -lh test.sh
----------. 1 atgadmin atgadmin 31 Jan 30 10:59 test.sh

[root ~]# ./test.sh
-bash: ./test.sh: Permission denied

[root ~]# sh test.sh
I'm alive! Thanks root!

@Shadur already said it so I'm just going to quote instead of restating it:

Note: The execution bit is checked for existence, not whether it's applicable to root.

  • 4
    root doesn't have execution permission unless at least one of the execution bits is set. – Stéphane Chazelas Jan 30 '15 at 15:44
  • And it's technically not so much "You don't have permission to execute this file" as it's "as far as I know this isn't an executable file" but the filesystem didn't see a point in adding the distinction. – Shadur Jan 30 '15 at 15:49
  • There should be an execution bit I agree, but root does have ways around that too from my experience, I have updated my answer with an example. Still a good point @StéphaneChazelas – devnull Jan 30 '15 at 16:07
  • 1
    The last example is not executing test.sh, but rather, is executing sh with one argument. The filesystem permission relevant to "sh test.sh" is read, not execute, as the sh program is reading in the file, not "executing" it. – dannysauer Feb 9 '15 at 16:27
  • 1
    I find this very confusing. You seem to be saying that the third group of permission bits apply to root (i.e., root is treated as an “other” user), so root has read/write access to the OP’s file.txt (which you call test.file) because the last digit of the mode is 6 (i.e., because the last three bits are rw-). That’s wrong. The fact that vi reports that root has “readonly” access to a 000 file is a red herring; I can’t tell what you are trying to show with that example. P.S. Rather than just demonstrating the rule for execution permission, it would be nice if you also stated it. – G-Man Says 'Reinstate Monica' Nov 10 '18 at 23:09

Root has full access to every file on the system by design. If you're looking to protect a file from accidental deletion, you can use

chattr +i file

This will set the immutable flag on GNU/Linux. You can remove it with -i instead of +i.

On FreeBSD, you can use

chflags schg file

Substitute noschg for schg to undo it.

If you're looking to protect a file from being visible to root, you should store your file on a different system, or use encryption as a last resort.

See also: https://superuser.com/questions/104015/removing-write-permission-does-not-prevent-root-from-writing-to-the-file


Could the rights be changed so that the root will have less permissions than the owner?

Shure, it is easy , Just change the passwd file so that root's uid is not zero. On the other hand don't do that it is bad idea.

You are not the first person to ask this question, and some of those people came up with the idea of capabilities, but we'll get to that in a bit, first let start with understanding the permission system works.

To start the part of the computer that does access checks does not know your name, it knows you by number, and that number is called a uid or user identifier. in a similar fashion it does not know the names of the groups you are a member of, just the gid. the mapping between uid and name is in the passwd file and the gid is mapped in the groups file.

Now when you want to open a file there are four checks that are made: do you have permission to skip the checks, are you as a user allowed to, are you as a member of a group allowed to, and as someone else are you allowed to. I'm skipping some stuff here like name service switch and access control lists and read write execute, but the part you are interested is that first test.

Sometimes you are allowed to skip the file permission tests. Why? and (very important) When? Now there are some things that sometimes need to be done that you don't want just anyone to do and don't fit into the file permission model very well. All sorts of things like open a network connection on a low port, mount a partition, or skip permission checks. These days these things are known as capabilities. In the old days, UID0 had all of these and there was nothing you could do about it, these days you can give capabilities to other users, or drop them, but the default is the old behavior.

The other way to restrict root is with something like selinux, but that is another ball of wax.


The previous answers assume that root has full access to everything. While this is true on most Unix variants, it is only partially true on modern (since the late 90's; kernel 2.2) Linux kernels. On modern Linux, elevated privileges are controlled by a capabilities model. By default, the kernel grants all capabilities to a program if it's running as UID 0. One of those capabilities is DAC_OVERRIDE, which overrides discretionary access control - AKA, file permissions. This is relevant because, on a 2.6.26 or later system (so, most up-to-date non-embedded Linux systems now), there is a securebits flag which can be set that disables some or all capabilities being provided to applications which switch to root or which start as root. To know what UID 0 can do, you technically have to know what capabilities are permitted to be inherited by processes running as UID 0.

So, usually root can do whatever whenever. But, if you're writing a program that needs to do things "as root" on Linux, you really need to familiarize yourself with the capabilities model and the functions associated with it. Don't be like so many vendors who write things that "need" to run suid root just to open a file or open a raw socket; define the capabilities that your program needs and test for those things. man capabilities.

  • My doubt was more on why root has the ability to read/write freely even when permission bits suggest otherwise than permissions root has in general. This answer was the closest! – pdp Sep 10 '15 at 12:12
  • What about the root group? Do users (who are non-root) who are part of the root group get special privileges as well? – CMCDragonkai Oct 27 '17 at 7:32
  • No, the root group is just another group in a user's list. In general, the root group isn't used for much, either; it's typically used more as a placeholder to fill in the group field for things owned by root. Generally, the only member of the root group would be root. – dannysauer Oct 27 '17 at 13:11

Which the rights for root in this case? Does it have 777?


As already stated, read and write permissions are not enforced for root. However, execution permission is still checked for presence so root would be unable to execute the file if no execute flag has been set. This is not the case here as the group has the x flag.

Note also that regardless of whether the write permission is granted or not, root or anyone will be refused write access to a file which is stored on a read-only file system.

Root might also have less rights than the owner if the file is stored on a remotely mounted directory like NFS.

Finally, note that symbolic links permissions are essentially meaningless.

  • 1
    Note: The execution bit is checked for existence, not whether it's applicable to root - create a directory as your own user and chmod it to 700 - root will walk right in. – Shadur Jan 30 '15 at 15:48
  • I assumed the question was about a plain file. Permissions might have indeed different effects when applied to directories, or are even essentially meaningless when on symbolic links. – jlliagre Jan 30 '15 at 17:10
  • 1
    No, this applies to regular files as well. If it's marked executable for anyone, it'll be executable for root. – Shadur Jan 30 '15 at 21:11
  • 1
    @Shadur I stand corrected, reply updated, thanks! – jlliagre Jan 31 '15 at 0:34
  • @Shadur: You seem to be confused.  The rule about checking for any execute bit to be set applies only to executing a plain file.  It does not apply to directories.  A root process will have full access to a directory with mode 000; i.e., no execute bits set. – G-Man Says 'Reinstate Monica' Nov 10 '18 at 23:12

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.