How do file permissions work for the «root» user?
Can anyone explain to me or point me to a tutorial that explains all of the rules that apply when the root user is dealing with files and directories?
6 Answers 6
Privileged access to files and directories is actually determined by capabilities, not just by being root or not. In practice, root usually has all possible capabilities, but there are situations where all/many of them could be dropped, or some given to other users (their processes).
In brief, you already described how the access control checks work for a privileged process. Here’s how the different capabilities actually affect it:
The main capability here is CAP_DAC_OVERRIDE , a process that has it can «bypass file read, write, and execute permission checks». That includes reading and writing to any files, as well as reading, writing and accessing directories.
It doesn’t actually apply to executing files that are not marked as executable. The comment in generic_permission ( fs/namei.c ), before the access checks for files, says that
Read/write DACs are always overridable. Executable DACs are overridable when there is at least one exec bit set.
And the code checks that there’s at least one x bit set if you’re trying to execute the file. I suspect that’s only a convenience feature, to prevent accidentally running random data files and getting errors or odd results.
Anyway, if you can override permissions, you could just make an executable copy and run that. (Though it might make a difference in theory for setuid files of a process was capable of overriding file permissions ( CAP_DAC_OVERRIDE ), but didn’t have other related capabilities ( CAP_FSETID / CAP_FOWNER / CAP_SETUID ). But having CAP_DAC_OVERRIDE allows editing /etc/shadow and stuff like that, so it’s approximately equal to just having full root access anyway.)
There’s also the CAP_DAC_READ_SEARCH capability that allows to read any files and access any directories, but not to execute or write to them; and CAP_FOWNER that allows a process to do stuff that’s usually reserved only for the file owner, like changing the permission bits and file group.
Overriding the sticky bit on directories is mentioned only under CAP_FOWNER , so it seems that CAP_DAC_OVERRIDE would not be enough to ignore that. (It would give you write permission, but usually in sticky directories you have that anyway, and +t limits it.)
(I think special devices count as «files» here. At least generic_permission() only has a type check for directories, but I didn’t check outside of that.)
Of course, there are still situations where even capabilities will not help you modify files:
- some files in /proc and /sys , since they’re not really actual files
- SELinux and other security modules that might limit root
- chattr immutable +i and append only +a flags on ext2/ext3/ext4, both of which stop even root, and prevent also file renames etc.
- network filesystems, where the server can do its own access control, e.g. root_squash in NFS maps root to nobody
- FUSE, which I assume could do anything
- read-only mounts
- read-only devices
I Can’t access the root folder
I do not have access to my root folder: Ubuntu says I do not have the necessary permissions to access it. I also cannot access lost + found , which gives me the same error message Is there anyone here that can provide answers to these questions?
@DevynCollierJohnson Probably not. It seems likely that this is asking about / (the root directory) rather than /root (root’s home directory). Furthermore, this also asks about lost+found (which is always in / but never in /root , since in practice /root is one of the few top-level directories nobody puts on a separate filesystem.
3 Answers 3
There are two different folders called the «root» folder: / (the root of the filesystem, which is really the only folder that should ever be called the «root folder»), and /root (the root user’s home directory). During the normal course of operation (i.e., except while performing administrative tasks), users cannot create new files in / or /root .
You should not change the ownership or permissions of either directory (changing them for / in particular could break things very badly, perhaps even beyond creating security problems depending on what assumptions your applications and services make about the ownership and permissions of / ).
If you have the gksu package installed, you can run gksudo nautilus to open a root-owned file browser window. If you do this, please be extra careful to only use it for tasks where you must be root, and to close it when you’re done (so you don’t later confuse it with an ordinary Nautilus window).
If you don’t have gksu installed and don’t want to install it, sudo -i nautilus or sudo -H nautilus are reasonably safe. (In contrast, if you were to use plain sudo nautilus , you might have to fix some things in your home directory to get Nautilus to work properly again when you’re not running it as root.)
However, usually you don’t need to do that either. You rarely have to manually edit the top-level contents of / or the contents of /root . I recommend providng more information—or asking a new question—to explain exactly what you’re trying to accomplish. The particular task you need to do will determine how you should proceed.
Finally, a note on lost+found . This stores files recovered in filesystem repair operations. Since such files could be from anywhere in the filesystem, it’s necessary to require root permissions to access them (or any information on the system could potentially be accessed by someone who is not an administrator). If you think there may be files there that you wish to reclaim, you can check by running
in a Terminal window ( Ctrl + Alt + T ).
If there are files there that you want, then you can copy them out (and if their ownership and permissions don’t give you the necessary access, change them). You can do that as root from the Terminal with cp , chmod and chown (run as root with sudo ), or with a root-owned Nautilus window as described above.
If you need to change ownership and permissions for files, then:
- make sure not to do so for more files than necessary—for example, some people accidentally change ownership or permissions for large parts of the system and then have to reinstall, and
- I recommend this guide for understanding the ownership/permissions system in Ubuntu (which also applies to most other Unix-like OSes). Wikipedia may help too.