If none of the execute permissions are set, root can't execute the file if any of them are set, he can. Because of this, even the root user obeys it - there's no point in executing a data file. The root user is generally immune from security restrictions (there are some exceptions, like immutable files, and modern features like capabilities have made this more fine-grained), which is why another name for this account is the "superuser".Įxecute permission is more of an advisory mode, distinguishing whether the file is intended to be executable or is just data. Read and write permissions are used to enforce security policies. root_squash in NFS maps root to nobodyĮxecute mode is treated a little bit differently from the other modes. network filesystems, where the server can do its own access control, e.g.chattr immutable +i and append only +a flags on ext2/ext3/ext4, both of which stop even root, and prevent also file renames etc.SELinux and other security modules that might limit root.some files in /proc and /sys, since they're not really actual files.Of course, there are still situations where even capabilities will not help you modify files: At least generic_permission() only has a type check for directories, but I didn't check outside of that.) (I think special devices count as "files" here. (It would give you write permission, but usually in sticky directories you have that anyway, and +t limits it.) 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. 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. 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.) (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). I suspect that's only a convenience feature, to prevent accidentally running random data files and getting errors or odd results.Īnyway, if you can override permissions, you could just make an executable copy and run that. Executable DACs are overridable when there is at least one exec bit set.Īnd the code checks that there's at least one x bit set if you're trying to execute the file. The comment in generic_permission ( fs/namei.c), before the access checks for files, says that It doesn't actually apply to executing files that are not marked as executable. That includes reading and writing to any files, as well as reading, writing and accessing directories. The main capability here is CAP_DAC_OVERRIDE, a process that has it can "bypass file read, write, and execute permission checks". Here's how the different capabilities actually affect it: In brief, you already described how the access control checks work for a privileged process. 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). Privileged access to files and directories is actually determined by capabilities, not just by being root or not.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |