Fsnameic

check_capabilities:

* Read/write DACs are always overridable.

* Executable DACs are overridable if at least one exec bit is set.

(inode->i_mode & S_IXUGO) || S_ISDIR(inode->i_mode)) if (capable(CAP_DAC_OVERRIDE)) return 0;

* Searching includes executable on directories, else just read.

if (mask == MAY_READ || (S_ISDIR(inode->i_mode) && !(mask & MAY_WRITE))) if (capable(CAP_DAC_READ_SEARCH)) return 0;

return -EACCES;

If the process possesses the capability dac_cap_override, the desired permission is granted if any of the following conditions holds:

□ Read or Write access, but not Execution access was requested.

□ Any of the three possible execution bits is set.

□ The inode represents a directory.

The other capability that comes into play is cap_dac_read_search, which grants the process the right to override DAC decisions when reading files and searching directories. If the capability is present, then access is granted if any of the following conditions holds:

□ A Read operation was requested.

□ The inode in question is a directory, and no Write access was requested.

Finally, the question remains how ACLs are taken into account. If the inode in question has an ACL associated with it (checked by is_posixacl) and a permission check callback for ACLs was passed to generic_permission, the callback is utilized right after the fsuid of the current task is compared with the UID of the file in question. If the desired access is denied, then process capabilities might still allow it. (Note that the DAC check can be skipped if an ACL callback is given because the standard DAC check is included in the ACL check.) Otherwise, the result of the ACL check is directly returned.

Continue reading here: Summary

Was this article helpful?

0 0