/* Ordinary permission routines do not understand MAY_APPEND. */ submask = mask & ~MAY_APPEND; if (inode->i_op && inode->i_op->permission)

retval = inode->i_op->permission(inode, submask, nd);

else retval = generic_permission(inode, submask, NULL);

if (retval)

return retval;

return security_inode_permission(inode, mask, nd);

If any of these denies the permission to access the object in the desired way, the error code is immediately returned. If they grant permission, that is, if their result is zero, it is still necessary to call the appropriate security hook via security_inode_permission, which delivers the final verdict.

Note that most filesystems rely on generic_permission, but can pass a special handler function to perform ACL-based permission checks. Thus, generic_permission not only requires the inode in question and the permission request as parameters, but also a callback function check_acl for ACL checks. First of all, the kernel needs to find out if it should use the inode rights for user, group, or other.

□ If the filesystem UID of the current process is the same as the UID of the inode, then the permission set of the owner needs to be used.

□ If the GID of the inode is contained in the list of groups to which the current process belongs, then the group permissions need to be used.

□ If both conditions fail, the permissions for ''other'' need to be used. This is implemented as follows:

Continue reading here: Fsnameic

Was this article helpful?

0 0