Construct a nameidata object and pass it down to permission(), so
that we can do the proper mount flag checks there.
Note that confining nfsd with AppArmor makes no sense, and so this
patch is not necessary for AppArmor alone.
Signed-off-by: Andreas Gruenbacher <[email protected]>
---
fs/nfsd/vfs.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1804,6 +1804,7 @@ nfsd_statfs(struct svc_rqst *rqstp, stru
__be32
nfsd_permission(struct svc_export *exp, struct dentry *dentry, int acc)
{
+ struct nameidata2 nd;
struct inode *inode = dentry->d_inode;
int err;
@@ -1869,12 +1870,16 @@ nfsd_permission(struct svc_export *exp,
inode->i_uid == current->fsuid)
return 0;
- err = permission(inode, acc & (MAY_READ|MAY_WRITE|MAY_EXEC), NULL);
+ nd.dentry = dentry;
+ nd.mnt = exp->ex_mnt;
+ nd.flags = LOOKUP_ACCESS;
+
+ err = permission(inode, acc & (MAY_READ|MAY_WRITE|MAY_EXEC), &nd);
/* Allow read access to binaries even when mode 111 */
if (err == -EACCES && S_ISREG(inode->i_mode) &&
acc == (MAY_READ | MAY_OWNER_OVERRIDE))
- err = permission(inode, MAY_EXEC, NULL);
+ err = permission(inode, MAY_EXEC, &nd);
return err? nfserrno(err) : 0;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
