d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

vfs: support denying access in vaccess_vexec_smr

Browse Source
This commit is contained in:
Mateusz Guzik 2020-08-23 21:05:06 +00:00
parent ba3b099198
commit 9ce9158b53
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=364539
1 changed files with 15 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
sys/kern/vfs_subr.c
View File

@ -5041,8 +5041,6 @@ vn_isdisk(struct vnode *vp)
/*
* VOP_FPLOOKUP_VEXEC routines are subject to special circumstances, see
* the comment above cache_fplookup for details.
*
* We never deny as priv_check_cred calls are not yet supported, see vaccess.
*/
int
vaccess_vexec_smr(mode_t file_mode, uid_t file_uid, gid_t file_gid, struct ucred *cred)
@ -5054,20 +5052,32 @@ vaccess_vexec_smr(mode_t file_mode, uid_t file_uid, gid_t file_gid, struct ucred
if (cred->cr_uid == file_uid) {
if (file_mode & S_IXUSR)
return (0);
return (EAGAIN);
goto out_error;
}
/* Otherwise, check the groups (first match) */
if (groupmember(file_gid, cred)) {
if (file_mode & S_IXGRP)
return (0);
return (EAGAIN);
goto out_error;
}
/* Otherwise, check everyone else. */
if (file_mode & S_IXOTH)
return (0);
return (EAGAIN);
out_error:
/*
* Permission check failed.
*
* vaccess() calls priv_check_cred which in turn can descent into MAC
* modules overriding this result. It's quite unclear what semantics
* are allowed for them to operate, thus for safety we don't call them
* from within the SMR section. This also means if any such modules
* are present, we have to let the regular lookup decide.
*/
if (__predict_false(mac_priv_check_fp_flag || mac_priv_grant_fp_flag))
return (EAGAIN);
return (EACCES);
}
/*