Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1233752 > unrolled thread
| Started by | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| First post | 2015-09-28 00:10 +0200 |
| Last post | 2015-10-06 00:10 +0200 |
| Articles | 17 on this page of 57 — 6 participants |
Back to article view | Back to linux.kernel
[PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:10 +0200
[PATCH v8 31/41] nfsd: Add support for the v4.1 dacl attribute Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 15/41] richacl: Automatic Inheritance Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 03/41] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 12/41] vfs: Cache richacl in struct inode Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 14/41] richacl: Create-time inheritance Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 33/41] richacl: Add support for unmapped identifiers Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 06/41] richacl: In-memory representation and helper functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 09/41] richacl: Update the file masks in chmod() Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
Re: [PATCH v8 09/41] richacl: Update the file masks in chmod() "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 17:30 +0200
Re: [PATCH v8 09/41] richacl: Update the file masks in chmod() Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-29 01:50 +0200
[PATCH v8 13/41] richacl: Check if an acl is equivalent to a file mode Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 27/41] richacl: Create richacl from mode values Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 19/41] ext4: Add richacl feature flag Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 21/41] richacl: Move everyone@ aces down the acl Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 20/41] richacl: acl editing helper functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 32/41] nfsd: Add support for the MAY_CREATE_{FILE,DIR} permissions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 26/41] richacl: Apply the file masks to a richacl Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 01/41] vfs: Add IS_ACL() and IS_RICHACL() tests Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 41/41] richacl: uapi header split Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 18/41] ext4: Add richacl support Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 17/41] vfs: Add richacl permission checking Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 35/41] sunrpc: Allow to demand-allocate pages to encode into Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 38/41] nfs: Remove unused xdr page offsets in getacl/setacl arguments Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 36/41] sunrpc: Add xdr_init_encode_pages Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 16/41] richacl: xattr mapping functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 25/41] richacl: Isolate the owner and group classes Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 40/41] nfs: Add support for the v4.1 dacl attribute Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 11/41] vfs: Cache base_acl objects in inodes Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 08/41] richacl: Compute maximum file masks from an acl Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 34/41] ext4: Don't allow unmapped identifiers in richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 05/41] vfs: Add permission flags for setting file attributes Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 28/41] nfsd: Keep list of acls to dispose of in compoundargs Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 04/41] vfs: Make the inode passed to inode_change_ok non-const Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 22/41] richacl: Propagate everyone@ permissions to other aces Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 37/41] nfs: Fix GETATTR bitmap verification Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 29/41] nfsd: Use richacls as internal acl representation Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 39/41] nfs: Add richacl support Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:20 +0200
[PATCH v8 24/41] richacl: Set the other permissions to the other mask Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:30 +0200
[PATCH v8 23/41] richacl: Set the owner permissions to the owner mask Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:30 +0200
[PATCH v8 30/41] nfsd: Add richacl support Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:30 +0200
[PATCH v8 07/41] richacl: Permission mapping functions Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:40 +0200
[PATCH v8 10/41] richacl: Permission check algorithm Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:40 +0200
Re: [PATCH v8 10/41] richacl: Permission check algorithm "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 18:10 +0200
Re: [PATCH v8 10/41] richacl: Permission check algorithm Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-28 18:30 +0200
Re: [PATCH v8 10/41] richacl: Permission check algorithm "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 18:30 +0200
Re: [PATCH v8 10/41] richacl: Permission check algorithm Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-28 19:00 +0200
[PATCH v8 02/41] vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags Andreas Gruenbacher <agruenba@redhat.com> - 2015-09-28 00:50 +0200
Re: [PATCH v8 00/41] Richacls "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 18:40 +0200
Re: [PATCH v8 00/41] Richacls Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-28 19:20 +0200
Re: [PATCH v8 00/41] Richacls "J. Bruce Fields" <bfields@fieldses.org> - 2015-09-28 19:50 +0200
Re: [PATCH v8 00/41] Richacls Andreas Grünbacher <andreas.gruenbacher@gmail.com> - 2015-09-29 17:00 +0200
Re: [PATCH v8 00/41] Richacls Christoph Hellwig <hch@infradead.org> - 2015-10-04 08:30 +0200
Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-05 20:50 +0200
Re: [PATCH v8 00/41] Richacls Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-10-05 21:00 +0200
Re: [PATCH v8 00/41] Richacls Dave Chinner <david@fromorbit.com> - 2015-10-05 23:20 +0200
Re: [PATCH v8 00/41] Richacls Andreas Gruenbacher <agruenba@redhat.com> - 2015-10-06 00:10 +0200
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2015-09-28 00:30 +0200 |
| Subject | [PATCH v8 30/41] nfsd: Add richacl support |
| Message-ID | <qdsCe-3EH-7@gated-at.bofh.it> |
| In reply to | #1233752 |
On file systems with richacls enabled, get and set richacls directly
instead of converting from / to posix acls.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Acked-by: J. Bruce Fields <bfields@redhat.com>
---
fs/nfsd/acl.h | 3 +-
fs/nfsd/nfs4acl.c | 124 ++++++++++++++++++++++++++++++++++++++---------------
fs/nfsd/nfs4proc.c | 2 +-
fs/nfsd/nfs4xdr.c | 34 +++++++++++----
4 files changed, 117 insertions(+), 46 deletions(-)
diff --git a/fs/nfsd/acl.h b/fs/nfsd/acl.h
index 1c5deb5..d73c664 100644
--- a/fs/nfsd/acl.h
+++ b/fs/nfsd/acl.h
@@ -53,8 +53,7 @@ __be32 nfsd4_decode_ace_who(struct richace *ace, struct svc_rqst *rqstp,
__be32 nfsd4_encode_ace_who(struct xdr_stream *xdr, struct svc_rqst *rqstp,
struct richace *ace);
-int nfsd4_get_acl(struct svc_rqst *rqstp, struct dentry *dentry,
- struct richacl **acl);
+struct richacl *nfsd4_get_acl(struct svc_rqst *rqstp, struct dentry *dentry);
__be32 nfsd4_set_acl(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct richacl *acl);
diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
index 6d3bb72..f017a76 100644
--- a/fs/nfsd/nfs4acl.c
+++ b/fs/nfsd/nfs4acl.c
@@ -40,6 +40,8 @@
#include <linux/nfs_fs.h>
#include <linux/richacl_compat.h>
#include <linux/nfs4acl.h>
+#include <linux/xattr.h>
+#include <linux/richacl_xattr.h>
#include "nfsfh.h"
#include "nfsd.h"
@@ -129,32 +131,28 @@ static short ace2type(struct richace *);
static void _posix_to_richacl_one(struct posix_acl *, struct richacl_alloc *,
unsigned int);
-int
-nfsd4_get_acl(struct svc_rqst *rqstp, struct dentry *dentry,
- struct richacl **acl)
+static struct richacl *
+nfsd4_get_posix_acl(struct svc_rqst *rqstp, struct dentry *dentry)
{
struct inode *inode = d_inode(dentry);
- int error = 0;
struct posix_acl *pacl = NULL, *dpacl = NULL;
struct richacl_alloc alloc;
unsigned int flags = 0;
int count;
pacl = get_acl(inode, ACL_TYPE_ACCESS);
- if (!pacl)
- pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL);
-
- if (IS_ERR(pacl))
- return PTR_ERR(pacl);
+ if (IS_ERR_OR_NULL(pacl))
+ return (void *)pacl;
- /* allocate for worst case: one (deny, allow) pair each: */
+ /* Allocate for worst case: one (deny, allow) pair each. The resulting
+ acl will be released shortly and won't be cached. */
count = 2 * pacl->a_count;
if (S_ISDIR(inode->i_mode)) {
flags = FLAG_DIRECTORY;
dpacl = get_acl(inode, ACL_TYPE_DEFAULT);
if (IS_ERR(dpacl)) {
- error = PTR_ERR(dpacl);
+ alloc.acl = (void *)dpacl;
goto rel_pacl;
}
@@ -163,7 +161,7 @@ nfsd4_get_acl(struct svc_rqst *rqstp, struct dentry *dentry,
}
if (!richacl_prepare(&alloc, count)) {
- error = -ENOMEM;
+ alloc.acl = ERR_PTR(-ENOMEM);
goto out;
}
@@ -172,13 +170,37 @@ nfsd4_get_acl(struct svc_rqst *rqstp, struct dentry *dentry,
if (dpacl)
_posix_to_richacl_one(dpacl, &alloc, flags | FLAG_DEFAULT_ACL);
- *acl = alloc.acl;
-
out:
posix_acl_release(dpacl);
rel_pacl:
posix_acl_release(pacl);
- return error;
+ return alloc.acl;
+}
+
+struct richacl *
+nfsd4_get_acl(struct svc_rqst *rqstp, struct dentry *dentry)
+{
+ struct inode *inode = d_inode(dentry);
+ struct richacl *acl;
+ int error;
+
+ if (IS_RICHACL(inode))
+ acl = get_richacl(inode);
+ else
+ acl = nfsd4_get_posix_acl(rqstp, dentry);
+ if (IS_ERR(acl))
+ return acl;
+ else if (acl == NULL) {
+ acl = richacl_from_mode(inode->i_mode);
+ if (acl == NULL)
+ acl = ERR_PTR(-ENOMEM);
+ }
+ error = richacl_apply_masks(&acl, inode->i_uid);
+ if (error) {
+ richacl_put(acl);
+ acl = ERR_PTR(error);
+ }
+ return acl;
}
struct posix_acl_summary {
@@ -744,56 +766,88 @@ out_estate:
return ret;
}
-__be32
-nfsd4_set_acl(struct svc_rqst *rqstp, struct svc_fh *fhp, struct richacl *acl)
+static int
+nfsd4_set_posix_acl(struct svc_rqst *rqstp, struct dentry *dentry,
+ struct richacl *acl)
{
- __be32 error;
int host_error;
- struct dentry *dentry;
- struct inode *inode;
+ struct inode *inode = d_inode(dentry);
struct posix_acl *pacl = NULL, *dpacl = NULL;
unsigned int flags = 0;
- /* Get inode */
- error = fh_verify(rqstp, fhp, 0, NFSD_MAY_SATTR);
- if (error)
- return error;
-
- dentry = fhp->fh_dentry;
- inode = d_inode(dentry);
-
if (!inode->i_op->set_acl || !IS_POSIXACL(inode))
- return nfserr_attrnotsupp;
+ return -EOPNOTSUPP;
if (S_ISDIR(inode->i_mode))
flags = FLAG_DIRECTORY;
host_error = nfs4_richacl_to_posix(acl, &pacl, &dpacl, flags);
if (host_error == -EINVAL)
- return nfserr_attrnotsupp;
+ return -EOPNOTSUPP;
if (host_error < 0)
- goto out_nfserr;
+ return host_error;
host_error = inode->i_op->set_acl(inode, pacl, ACL_TYPE_ACCESS);
if (host_error < 0)
goto out_release;
- if (S_ISDIR(inode->i_mode)) {
+ if (S_ISDIR(inode->i_mode))
host_error = inode->i_op->set_acl(inode, dpacl,
ACL_TYPE_DEFAULT);
- }
out_release:
posix_acl_release(pacl);
posix_acl_release(dpacl);
-out_nfserr:
+ return host_error;
+}
+
+static int
+nfsd4_set_richacl(struct svc_rqst *rqstp, struct dentry *dentry,
+ struct richacl *acl)
+{
+ int host_error;
+ struct inode *inode = d_inode(dentry);
+ size_t size = richacl_xattr_size(acl);
+ char *buffer;
+
+ if (!inode->i_op->setxattr || !IS_RICHACL(inode))
+ return -EOPNOTSUPP;
+
+ richacl_compute_max_masks(acl);
+
+ buffer = kmalloc(size, GFP_KERNEL);
+ if (!buffer)
+ return -ENOMEM;
+ richacl_to_xattr(&init_user_ns, acl, buffer, size);
+ host_error = inode->i_op->setxattr(dentry, XATTR_NAME_RICHACL,
+ buffer, size, 0);
+ kfree(buffer);
+ return host_error;
+}
+
+__be32
+nfsd4_set_acl(struct svc_rqst *rqstp, struct svc_fh *fhp, struct richacl *acl)
+{
+ struct dentry *dentry;
+ int host_error;
+ __be32 error;
+
+ error = fh_verify(rqstp, fhp, 0, NFSD_MAY_SATTR);
+ if (error)
+ return error;
+ dentry = fhp->fh_dentry;
+
+ if (IS_RICHACL(d_inode(dentry)))
+ host_error = nfsd4_set_richacl(rqstp, dentry, acl);
+ else
+ host_error = nfsd4_set_posix_acl(rqstp, dentry, acl);
+
if (host_error == -EOPNOTSUPP)
return nfserr_attrnotsupp;
else
return nfserrno(host_error);
}
-
static short
ace2type(struct richace *ace)
{
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 2430235..1bcfda2 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -110,7 +110,7 @@ check_attr_support(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
* in current environment or not.
*/
if (bmval[0] & FATTR4_WORD0_ACL) {
- if (!IS_POSIXACL(d_inode(dentry)))
+ if (!IS_ACL(d_inode(dentry)))
return nfserr_attrnotsupp;
}
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 8603f40..682a7d8 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -340,11 +340,24 @@ nfsd4_decode_fattr(struct nfsd4_compoundargs *argp, u32 *bmval,
richacl_for_each_entry(ace, *acl) {
READ_BUF(16); len += 16;
- ace->e_type = be32_to_cpup(p++);
- ace->e_flags = be32_to_cpup(p++);
- ace->e_mask = be32_to_cpup(p++);
- if (ace->e_flags & RICHACE_SPECIAL_WHO)
+
+ dummy32 = be32_to_cpup(p++);
+ if (dummy32 > RICHACE_ACCESS_DENIED_ACE_TYPE)
+ return nfserr_inval;
+ ace->e_type = dummy32;
+
+ dummy32 = be32_to_cpup(p++);
+ if (dummy32 & (~RICHACE_VALID_FLAGS |
+ RICHACE_INHERITED_ACE |
+ RICHACE_SPECIAL_WHO))
return nfserr_inval;
+ ace->e_flags = dummy32;
+
+ dummy32 = be32_to_cpup(p++);
+ if (dummy32 & ~NFS4_ACE_MASK_ALL)
+ return nfserr_inval;
+ ace->e_mask = dummy32;
+
dummy32 = be32_to_cpup(p++);
READ_BUF(dummy32);
len += XDR_QUADLEN(dummy32) << 2;
@@ -2330,7 +2343,11 @@ nfsd4_encode_fattr(struct xdr_stream *xdr, struct svc_fh *fhp,
fhp = tempfh;
}
if (bmval0 & FATTR4_WORD0_ACL) {
- err = nfsd4_get_acl(rqstp, dentry, &acl);
+ acl = nfsd4_get_acl(rqstp, dentry);
+ if (IS_ERR(acl)) {
+ err = PTR_ERR(acl);
+ acl = NULL;
+ }
if (err == -EOPNOTSUPP)
bmval0 &= ~FATTR4_WORD0_ACL;
else if (err == -EINVAL) {
@@ -2370,7 +2387,7 @@ nfsd4_encode_fattr(struct xdr_stream *xdr, struct svc_fh *fhp,
u32 word1 = nfsd_suppattrs1(minorversion);
u32 word2 = nfsd_suppattrs2(minorversion);
- if (!IS_POSIXACL(dentry->d_inode))
+ if (!IS_ACL(d_inode(dentry)))
word0 &= ~FATTR4_WORD0_ACL;
if (!contextsupport)
word2 &= ~FATTR4_WORD2_SECURITY_LABEL;
@@ -2505,7 +2522,8 @@ nfsd4_encode_fattr(struct xdr_stream *xdr, struct svc_fh *fhp,
if (!p)
goto out_resource;
*p++ = cpu_to_be32(ace->e_type);
- *p++ = cpu_to_be32(ace->e_flags & ~RICHACE_SPECIAL_WHO);
+ *p++ = cpu_to_be32(ace->e_flags &
+ ~(RICHACE_SPECIAL_WHO | RICHACE_INHERITED_ACE));
*p++ = cpu_to_be32(ace->e_mask & NFS4_ACE_MASK_ALL);
status = nfsd4_encode_ace_who(xdr, rqstp, ace);
if (status)
@@ -2517,7 +2535,7 @@ out_acl:
p = xdr_reserve_space(xdr, 4);
if (!p)
goto out_resource;
- *p++ = cpu_to_be32(IS_POSIXACL(dentry->d_inode) ?
+ *p++ = cpu_to_be32(IS_ACL(d_inode(dentry)) ?
ACL4_SUPPORT_ALLOW_ACL|ACL4_SUPPORT_DENY_ACL : 0);
}
if (bmval0 & FATTR4_WORD0_CANSETTIME) {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2015-09-28 00:40 +0200 |
| Subject | [PATCH v8 07/41] richacl: Permission mapping functions |
| Message-ID | <qdsLU-3PM-3@gated-at.bofh.it> |
| In reply to | #1233752 |
We need to map from POSIX permissions to NFSv4 permissions when a
chmod() is done, from NFSv4 permissions to POSIX permissions when an acl
is set (which implicitly sets the file permission bits), and from the
MAY_READ/MAY_WRITE/MAY_EXEC/MAY_APPEND flags to NFSv4 permissions when
doing an access check in a richacl.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: J. Bruce Fields <bfields@redhat.com>
---
fs/richacl_base.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/richacl.h | 47 ++++++++++++++++++-
2 files changed, 163 insertions(+), 1 deletion(-)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index 6d9a073..063dbe4 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -65,3 +65,120 @@ richace_copy(struct richace *to, const struct richace *from)
{
memcpy(to, from, sizeof(struct richace));
}
+
+/*
+ * richacl_mask_to_mode - compute the file permission bits from mask
+ * @mask: %RICHACE_* permission mask
+ *
+ * Compute the file permission bits corresponding to a particular set of
+ * richacl permissions.
+ *
+ * See richacl_masks_to_mode().
+ */
+static int
+richacl_mask_to_mode(unsigned int mask)
+{
+ int mode = 0;
+
+ if (mask & RICHACE_POSIX_MODE_READ)
+ mode |= S_IROTH;
+ if (mask & RICHACE_POSIX_MODE_WRITE)
+ mode |= S_IWOTH;
+ if (mask & RICHACE_POSIX_MODE_EXEC)
+ mode |= S_IXOTH;
+
+ return mode;
+}
+
+/**
+ * richacl_masks_to_mode - compute file permission bits from file masks
+ *
+ * When setting a richacl, we set the file permission bits to indicate maximum
+ * permissions: for example, we set the Write permission when a mask contains
+ * RICHACE_APPEND_DATA even if it does not also contain RICHACE_WRITE_DATA.
+ *
+ * Permissions which are not in RICHACE_POSIX_MODE_READ,
+ * RICHACE_POSIX_MODE_WRITE, or RICHACE_POSIX_MODE_EXEC cannot be represented
+ * in the file permission bits. Such permissions can still be effective, but
+ * not for new files or after a chmod(); they must be explicitly enabled in the
+ * richacl.
+ */
+int
+richacl_masks_to_mode(const struct richacl *acl)
+{
+ return richacl_mask_to_mode(acl->a_owner_mask) << 6 |
+ richacl_mask_to_mode(acl->a_group_mask) << 3 |
+ richacl_mask_to_mode(acl->a_other_mask);
+}
+EXPORT_SYMBOL_GPL(richacl_masks_to_mode);
+
+/**
+ * richacl_mode_to_mask - compute a file mask from the lowest three mode bits
+ *
+ * When the file permission bits of a file are set with chmod(), this specifies
+ * the maximum permissions that processes will get. All permissions beyond
+ * that will be removed from the file masks, and become ineffective.
+ */
+unsigned int
+richacl_mode_to_mask(mode_t mode)
+{
+ unsigned int mask = 0;
+
+ if (mode & S_IROTH)
+ mask |= RICHACE_POSIX_MODE_READ;
+ if (mode & S_IWOTH)
+ mask |= RICHACE_POSIX_MODE_WRITE;
+ if (mode & S_IXOTH)
+ mask |= RICHACE_POSIX_MODE_EXEC;
+
+ return mask;
+}
+
+/**
+ * richacl_want_to_mask - convert the iop->permission want argument to a mask
+ * @want: @want argument of the permission inode operation
+ *
+ * When checking for append, @want is (MAY_WRITE | MAY_APPEND).
+ *
+ * Richacls use the iop->may_create and iop->may_delete hooks which are used
+ * for checking if creating and deleting files is allowed. These hooks do not
+ * use richacl_want_to_mask(), so we do not have to deal with mapping MAY_WRITE
+ * to RICHACE_ADD_FILE, RICHACE_ADD_SUBDIRECTORY, and RICHACE_DELETE_CHILD
+ * here.
+ */
+unsigned int
+richacl_want_to_mask(unsigned int want)
+{
+ unsigned int mask = 0;
+
+ if (want & MAY_READ)
+ mask |= RICHACE_READ_DATA;
+ if (want & MAY_DELETE_SELF)
+ mask |= RICHACE_DELETE;
+ if (want & MAY_TAKE_OWNERSHIP)
+ mask |= RICHACE_WRITE_OWNER;
+ if (want & MAY_CHMOD)
+ mask |= RICHACE_WRITE_ACL;
+ if (want & MAY_SET_TIMES)
+ mask |= RICHACE_WRITE_ATTRIBUTES;
+ if (want & MAY_EXEC)
+ mask |= RICHACE_EXECUTE;
+ /*
+ * differentiate MAY_WRITE from these request
+ */
+ if (want & (MAY_APPEND |
+ MAY_CREATE_FILE | MAY_CREATE_DIR |
+ MAY_DELETE_CHILD)) {
+ if (want & MAY_APPEND)
+ mask |= RICHACE_APPEND_DATA;
+ if (want & MAY_CREATE_FILE)
+ mask |= RICHACE_ADD_FILE;
+ if (want & MAY_CREATE_DIR)
+ mask |= RICHACE_ADD_SUBDIRECTORY;
+ if (want & MAY_DELETE_CHILD)
+ mask |= RICHACE_DELETE_CHILD;
+ } else if (want & MAY_WRITE)
+ mask |= RICHACE_WRITE_DATA;
+ return mask;
+}
+EXPORT_SYMBOL_GPL(richacl_want_to_mask);
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index bfa94bb..9c8f298 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -126,6 +126,49 @@ struct richacl {
RICHACE_WRITE_OWNER | \
RICHACE_SYNCHRONIZE)
+/*
+ * The POSIX permissions are supersets of the following NFSv4 permissions:
+ *
+ * - MAY_READ maps to READ_DATA or LIST_DIRECTORY, depending on the type
+ * of the file system object.
+ *
+ * - MAY_WRITE maps to WRITE_DATA or RICHACE_APPEND_DATA for files, and to
+ * ADD_FILE, RICHACE_ADD_SUBDIRECTORY, or RICHACE_DELETE_CHILD for directories.
+ *
+ * - MAY_EXECUTE maps to RICHACE_EXECUTE.
+ *
+ * (Some of these NFSv4 permissions have the same bit values.)
+ */
+#define RICHACE_POSIX_MODE_READ ( \
+ RICHACE_READ_DATA | \
+ RICHACE_LIST_DIRECTORY)
+#define RICHACE_POSIX_MODE_WRITE ( \
+ RICHACE_WRITE_DATA | \
+ RICHACE_ADD_FILE | \
+ RICHACE_APPEND_DATA | \
+ RICHACE_ADD_SUBDIRECTORY | \
+ RICHACE_DELETE_CHILD)
+#define RICHACE_POSIX_MODE_EXEC RICHACE_EXECUTE
+#define RICHACE_POSIX_MODE_ALL ( \
+ RICHACE_POSIX_MODE_READ | \
+ RICHACE_POSIX_MODE_WRITE | \
+ RICHACE_POSIX_MODE_EXEC)
+/*
+ * These permissions are always allowed
+ * no matter what the acl says.
+ */
+#define RICHACE_POSIX_ALWAYS_ALLOWED ( \
+ RICHACE_SYNCHRONIZE | \
+ RICHACE_READ_ATTRIBUTES | \
+ RICHACE_READ_ACL)
+/*
+ * The owner is implicitly granted
+ * these permissions under POSIX.
+ */
+#define RICHACE_POSIX_OWNER_ALLOWED ( \
+ RICHACE_WRITE_ATTRIBUTES | \
+ RICHACE_WRITE_OWNER | \
+ RICHACE_WRITE_ACL)
/**
* richacl_get - grab another reference to a richacl handle
*/
@@ -251,6 +294,8 @@ richace_is_same_identifier(const struct richace *a, const struct richace *b)
extern struct richacl *richacl_alloc(int, gfp_t);
extern struct richacl *richacl_clone(const struct richacl *, gfp_t);
extern void richace_copy(struct richace *, const struct richace *);
-
+extern int richacl_masks_to_mode(const struct richacl *);
+extern unsigned int richacl_mode_to_mask(mode_t);
+extern unsigned int richacl_want_to_mask(unsigned int);
#endif /* __RICHACL_H */
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2015-09-28 00:40 +0200 |
| Subject | [PATCH v8 10/41] richacl: Permission check algorithm |
| Message-ID | <qdsLU-3PM-5@gated-at.bofh.it> |
| In reply to | #1233752 |
A richacl roughly grants a requested access if the NFSv4 acl in the
richacl grants the requested permissions according to the NFSv4
permission check algorithm and the file mask that applies to the process
includes the requested permissions.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: "J. Bruce Fields" <bfields@fieldses.org>
---
fs/Makefile | 2 +-
fs/richacl_inode.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/richacl.h | 3 +
3 files changed, 152 insertions(+), 1 deletion(-)
create mode 100644 fs/richacl_inode.c
diff --git a/fs/Makefile b/fs/Makefile
index fe3e9dd..ec665fd 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_SYSCTL) += drop_caches.o
obj-$(CONFIG_FHANDLE) += fhandle.o
obj-$(CONFIG_FS_RICHACL) += richacl.o
-richacl-y := richacl_base.o
+richacl-y := richacl_base.o richacl_inode.o
obj-y += quota/
diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
new file mode 100644
index 0000000..54e899d
--- /dev/null
+++ b/fs/richacl_inode.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2010 Novell, Inc.
+ * Copyright (C) 2015 Red Hat, Inc.
+ * Written by Andreas Gruenbacher <agruen@kernel.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/sched.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/richacl.h>
+
+/**
+ * richacl_permission - richacl permission check algorithm
+ * @inode: inode to check
+ * @acl: rich acl of the inode
+ * @want: requested access (MAY_* flags)
+ *
+ * Checks if the current process is granted @mask flags in @acl.
+ */
+int
+richacl_permission(struct inode *inode, const struct richacl *acl,
+ int want)
+{
+ const struct richace *ace;
+ unsigned int mask = richacl_want_to_mask(want);
+ unsigned int requested = mask, denied = 0;
+ int in_owning_group = in_group_p(inode->i_gid);
+ int in_owner_or_group_class = in_owning_group;
+
+ /*
+ * A process is
+ * - in the owner file class if it owns the file,
+ * - in the group file class if it is in the file's owning group or
+ * it matches any of the user or group entries, and
+ * - in the other file class otherwise.
+ * The file class is only relevant for determining which file mask to
+ * apply, which only happens for masked acls.
+ */
+ if (acl->a_flags & RICHACL_MASKED) {
+ if ((acl->a_flags & RICHACL_WRITE_THROUGH) &&
+ uid_eq(current_fsuid(), inode->i_uid)) {
+ denied = requested & ~acl->a_owner_mask;
+ goto out;
+ }
+ } else {
+ /*
+ * When the acl is not masked, there is no need to determine if
+ * the process is in the group class and we can break out
+ * earlier of the loop below.
+ */
+ in_owner_or_group_class = 1;
+ }
+
+ /*
+ * Check if the acl grants the requested access and determine which
+ * file class the process is in.
+ */
+ richacl_for_each_entry(ace, acl) {
+ unsigned int ace_mask = ace->e_mask;
+
+ if (richace_is_inherit_only(ace))
+ continue;
+ if (richace_is_owner(ace)) {
+ if (!uid_eq(current_fsuid(), inode->i_uid))
+ continue;
+ goto entry_matches_owner;
+ } else if (richace_is_group(ace)) {
+ if (!in_owning_group)
+ continue;
+ } else if (richace_is_unix_user(ace)) {
+ if (!uid_eq(current_fsuid(), ace->e_id.uid))
+ continue;
+ goto entry_matches_owner;
+ } else if (richace_is_unix_group(ace)) {
+ if (!in_group_p(ace->e_id.gid))
+ continue;
+ } else
+ goto entry_matches_everyone;
+
+ /*
+ * Apply the group file mask to entries other than owner@ and
+ * everyone@ or user entries matching the owner. This ensures
+ * that we grant the same permissions as the acl computed by
+ * richacl_apply_masks().
+ *
+ * Without this restriction, the following richacl would grant
+ * rw access to processes which are both the owner and in the
+ * owning group, but not to other users in the owning group,
+ * which could not be represented without masks:
+ *
+ * owner:rw::mask
+ * group@:rw::allow
+ */
+ if ((acl->a_flags & RICHACL_MASKED) && richace_is_allow(ace))
+ ace_mask &= acl->a_group_mask;
+
+entry_matches_owner:
+ /* The process is in the owner or group file class. */
+ in_owner_or_group_class = 1;
+
+entry_matches_everyone:
+ /* Check which mask flags the ACE allows or denies. */
+ if (richace_is_deny(ace))
+ denied |= ace_mask & mask;
+ mask &= ~ace_mask;
+
+ /*
+ * Keep going until we know which file class
+ * the process is in.
+ */
+ if (!mask && in_owner_or_group_class)
+ break;
+ }
+ denied |= mask;
+
+ if (acl->a_flags & RICHACL_MASKED) {
+ /*
+ * The file class a process is in determines which file mask
+ * applies. Check if that file mask also grants the requested
+ * access.
+ */
+ if (uid_eq(current_fsuid(), inode->i_uid))
+ denied |= requested & ~acl->a_owner_mask;
+ else if (in_owner_or_group_class)
+ denied |= requested & ~acl->a_group_mask;
+ else {
+ if (acl->a_flags & RICHACL_WRITE_THROUGH)
+ denied = requested & ~acl->a_other_mask;
+ else
+ denied |= requested & ~acl->a_other_mask;
+ }
+ }
+
+out:
+ return denied ? -EACCES : 0;
+}
+EXPORT_SYMBOL_GPL(richacl_permission);
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index e00f313..9768eeb 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -300,4 +300,7 @@ extern unsigned int richacl_want_to_mask(unsigned int);
extern void richacl_compute_max_masks(struct richacl *);
extern struct richacl *richacl_chmod(struct richacl *, mode_t);
+/* richacl_inode.c */
+extern int richacl_permission(struct inode *, const struct richacl *, int);
+
#endif /* __RICHACL_H */
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "J. Bruce Fields" <bfields@fieldses.org> |
|---|---|
| Date | 2015-09-28 18:10 +0200 |
| Subject | Re: [PATCH v8 10/41] richacl: Permission check algorithm |
| Message-ID | <qdJa2-4l8-33@gated-at.bofh.it> |
| In reply to | #1233793 |
On Mon, Sep 28, 2015 at 12:09:01AM +0200, Andreas Gruenbacher wrote:
> A richacl roughly grants a requested access if the NFSv4 acl in the
> richacl grants the requested permissions according to the NFSv4
> permission check algorithm and the file mask that applies to the process
> includes the requested permissions.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> Reviewed-by: "J. Bruce Fields" <bfields@fieldses.org>
> ---
> fs/Makefile | 2 +-
> fs/richacl_inode.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/richacl.h | 3 +
> 3 files changed, 152 insertions(+), 1 deletion(-)
> create mode 100644 fs/richacl_inode.c
>
> diff --git a/fs/Makefile b/fs/Makefile
> index fe3e9dd..ec665fd 100644
> --- a/fs/Makefile
> +++ b/fs/Makefile
> @@ -49,7 +49,7 @@ obj-$(CONFIG_SYSCTL) += drop_caches.o
>
> obj-$(CONFIG_FHANDLE) += fhandle.o
> obj-$(CONFIG_FS_RICHACL) += richacl.o
> -richacl-y := richacl_base.o
> +richacl-y := richacl_base.o richacl_inode.o
>
> obj-y += quota/
>
> diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
> new file mode 100644
> index 0000000..54e899d
> --- /dev/null
> +++ b/fs/richacl_inode.c
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright (C) 2010 Novell, Inc.
> + * Copyright (C) 2015 Red Hat, Inc.
> + * Written by Andreas Gruenbacher <agruen@kernel.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2, or (at your option) any
> + * later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/sched.h>
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/slab.h>
> +#include <linux/richacl.h>
> +
> +/**
> + * richacl_permission - richacl permission check algorithm
> + * @inode: inode to check
> + * @acl: rich acl of the inode
> + * @want: requested access (MAY_* flags)
> + *
> + * Checks if the current process is granted @mask flags in @acl.
> + */
> +int
> +richacl_permission(struct inode *inode, const struct richacl *acl,
> + int want)
> +{
> + const struct richace *ace;
> + unsigned int mask = richacl_want_to_mask(want);
> + unsigned int requested = mask, denied = 0;
> + int in_owning_group = in_group_p(inode->i_gid);
> + int in_owner_or_group_class = in_owning_group;
> +
> + /*
> + * A process is
> + * - in the owner file class if it owns the file,
> + * - in the group file class if it is in the file's owning group or
> + * it matches any of the user or group entries, and
> + * - in the other file class otherwise.
> + * The file class is only relevant for determining which file mask to
> + * apply, which only happens for masked acls.
> + */
> + if (acl->a_flags & RICHACL_MASKED) {
> + if ((acl->a_flags & RICHACL_WRITE_THROUGH) &&
> + uid_eq(current_fsuid(), inode->i_uid)) {
> + denied = requested & ~acl->a_owner_mask;
> + goto out;
> + }
> + } else {
> + /*
> + * When the acl is not masked, there is no need to determine if
> + * the process is in the group class and we can break out
> + * earlier of the loop below.
> + */
> + in_owner_or_group_class = 1;
> + }
> +
> + /*
> + * Check if the acl grants the requested access and determine which
> + * file class the process is in.
> + */
> + richacl_for_each_entry(ace, acl) {
> + unsigned int ace_mask = ace->e_mask;
> +
> + if (richace_is_inherit_only(ace))
> + continue;
> + if (richace_is_owner(ace)) {
> + if (!uid_eq(current_fsuid(), inode->i_uid))
> + continue;
> + goto entry_matches_owner;
> + } else if (richace_is_group(ace)) {
> + if (!in_owning_group)
> + continue;
> + } else if (richace_is_unix_user(ace)) {
> + if (!uid_eq(current_fsuid(), ace->e_id.uid))
> + continue;
> + goto entry_matches_owner;
> + } else if (richace_is_unix_group(ace)) {
> + if (!in_group_p(ace->e_id.gid))
> + continue;
> + } else
> + goto entry_matches_everyone;
> +
> + /*
> + * Apply the group file mask to entries other than owner@ and
> + * everyone@ or user entries matching the owner.
The above also skips the following group_mask application on any unix
group. But that's OK, since a non-owner matching a unix group will be
placed into the group class, so the RICHACL_MASKED clause after the loop
below will apply the group mask. That logic is a little subtle, but OK.
--b.
> This ensures
> + * that we grant the same permissions as the acl computed by
> + * richacl_apply_masks().
> + *
> + * Without this restriction, the following richacl would grant
> + * rw access to processes which are both the owner and in the
> + * owning group, but not to other users in the owning group,
> + * which could not be represented without masks:
> + *
> + * owner:rw::mask
> + * group@:rw::allow
> + */
> + if ((acl->a_flags & RICHACL_MASKED) && richace_is_allow(ace))
> + ace_mask &= acl->a_group_mask;
> +
> +entry_matches_owner:
> + /* The process is in the owner or group file class. */
> + in_owner_or_group_class = 1;
> +
> +entry_matches_everyone:
> + /* Check which mask flags the ACE allows or denies. */
> + if (richace_is_deny(ace))
> + denied |= ace_mask & mask;
> + mask &= ~ace_mask;
> +
> + /*
> + * Keep going until we know which file class
> + * the process is in.
> + */
> + if (!mask && in_owner_or_group_class)
> + break;
> + }
> + denied |= mask;
> +
> + if (acl->a_flags & RICHACL_MASKED) {
> + /*
> + * The file class a process is in determines which file mask
> + * applies. Check if that file mask also grants the requested
> + * access.
> + */
> + if (uid_eq(current_fsuid(), inode->i_uid))
> + denied |= requested & ~acl->a_owner_mask;
> + else if (in_owner_or_group_class)
> + denied |= requested & ~acl->a_group_mask;
> + else {
> + if (acl->a_flags & RICHACL_WRITE_THROUGH)
> + denied = requested & ~acl->a_other_mask;
> + else
> + denied |= requested & ~acl->a_other_mask;
> + }
> + }
> +
> +out:
> + return denied ? -EACCES : 0;
> +}
> +EXPORT_SYMBOL_GPL(richacl_permission);
> diff --git a/include/linux/richacl.h b/include/linux/richacl.h
> index e00f313..9768eeb 100644
> --- a/include/linux/richacl.h
> +++ b/include/linux/richacl.h
> @@ -300,4 +300,7 @@ extern unsigned int richacl_want_to_mask(unsigned int);
> extern void richacl_compute_max_masks(struct richacl *);
> extern struct richacl *richacl_chmod(struct richacl *, mode_t);
>
> +/* richacl_inode.c */
> +extern int richacl_permission(struct inode *, const struct richacl *, int);
> +
> #endif /* __RICHACL_H */
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Grünbacher <andreas.gruenbacher@gmail.com> |
|---|---|
| Date | 2015-09-28 18:30 +0200 |
| Subject | Re: [PATCH v8 10/41] richacl: Permission check algorithm |
| Message-ID | <qdJtp-4HM-17@gated-at.bofh.it> |
| In reply to | #1234271 |
2015-09-28 18:08 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>:
> On Mon, Sep 28, 2015 at 12:09:01AM +0200, Andreas Gruenbacher wrote:
>> + /*
>> + * Check if the acl grants the requested access and determine which
>> + * file class the process is in.
>> + */
>> + richacl_for_each_entry(ace, acl) {
>> + unsigned int ace_mask = ace->e_mask;
>> +
>> + if (richace_is_inherit_only(ace))
>> + continue;
>> + if (richace_is_owner(ace)) {
>> + if (!uid_eq(current_fsuid(), inode->i_uid))
>> + continue;
>> + goto entry_matches_owner;
>> + } else if (richace_is_group(ace)) {
>> + if (!in_owning_group)
>> + continue;
>> + } else if (richace_is_unix_user(ace)) {
>> + if (!uid_eq(current_fsuid(), ace->e_id.uid))
>> + continue;
>> + goto entry_matches_owner;
>> + } else if (richace_is_unix_group(ace)) {
>> + if (!in_group_p(ace->e_id.gid))
>> + continue;
>> + } else
>> + goto entry_matches_everyone;
>> +
>> + /*
>> + * Apply the group file mask to entries other than owner@ and
>> + * everyone@ or user entries matching the owner.
>
> The above also skips the following group_mask application on any unix
> group.
Really? How does it do that?
Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "J. Bruce Fields" <bfields@fieldses.org> |
|---|---|
| Date | 2015-09-28 18:30 +0200 |
| Subject | Re: [PATCH v8 10/41] richacl: Permission check algorithm |
| Message-ID | <qdJtp-4HM-23@gated-at.bofh.it> |
| In reply to | #1234277 |
On Mon, Sep 28, 2015 at 06:25:23PM +0200, Andreas Grünbacher wrote:
> 2015-09-28 18:08 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>:
> > On Mon, Sep 28, 2015 at 12:09:01AM +0200, Andreas Gruenbacher wrote:
> >> + /*
> >> + * Check if the acl grants the requested access and determine which
> >> + * file class the process is in.
> >> + */
> >> + richacl_for_each_entry(ace, acl) {
> >> + unsigned int ace_mask = ace->e_mask;
> >> +
> >> + if (richace_is_inherit_only(ace))
> >> + continue;
> >> + if (richace_is_owner(ace)) {
> >> + if (!uid_eq(current_fsuid(), inode->i_uid))
> >> + continue;
> >> + goto entry_matches_owner;
> >> + } else if (richace_is_group(ace)) {
> >> + if (!in_owning_group)
> >> + continue;
> >> + } else if (richace_is_unix_user(ace)) {
> >> + if (!uid_eq(current_fsuid(), ace->e_id.uid))
> >> + continue;
> >> + goto entry_matches_owner;
> >> + } else if (richace_is_unix_group(ace)) {
> >> + if (!in_group_p(ace->e_id.gid))
> >> + continue;
> >> + } else
> >> + goto entry_matches_everyone;
> >> +
> >> + /*
> >> + * Apply the group file mask to entries other than owner@ and
> >> + * everyone@ or user entries matching the owner.
> >
> > The above also skips the following group_mask application on any unix
> > group.
>
> Really? How does it do that?
Sorry, I meant "unix user", not "unix group"!
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Grünbacher <andreas.gruenbacher@gmail.com> |
|---|---|
| Date | 2015-09-28 19:00 +0200 |
| Subject | Re: [PATCH v8 10/41] richacl: Permission check algorithm |
| Message-ID | <qdJWr-5fG-19@gated-at.bofh.it> |
| In reply to | #1234278 |
2015-09-28 18:29 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: > On Mon, Sep 28, 2015 at 06:25:23PM +0200, Andreas Grünbacher wrote: >> 2015-09-28 18:08 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: >> > The above also skips the following group_mask application on any unix >> > group. >> >> Really? How does it do that? > > Sorry, I meant "unix user", not "unix group"! Indeed, that's a bit tricky. Probably worth changing if just for clarity: - goto entry_matches_owner; + if (uid_eq(current_fsuid(), inode->i_uid)) + goto entry_matches_owner; Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2015-09-28 00:50 +0200 |
| Subject | [PATCH v8 02/41] vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags |
| Message-ID | <qdsVz-419-3@gated-at.bofh.it> |
| In reply to | #1233752 |
Richacls distinguish between creating non-directories and directories. To
support that, add an isdir parameter to may_create(). When checking
inode_permission() for create permission, pass in an additional
MAY_CREATE_FILE or MAY_CREATE_DIR mask flag.
To allow checking for delete *and* create access when replacing an existing
file via vfs_rename(), add a replace parameter to may_delete().
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: J. Bruce Fields <bfields@redhat.com>
---
fs/namei.c | 43 +++++++++++++++++++++++++------------------
include/linux/fs.h | 2 ++
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 48c2752..7c0f310 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -453,7 +453,9 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask)
* this, letting us set arbitrary permissions for filesystem access without
* changing the "normal" UIDs which are used for other things.
*
- * When checking for MAY_APPEND, MAY_WRITE must also be set in @mask.
+ * MAY_WRITE must be set in @mask whenever MAY_APPEND, MAY_CREATE_FILE, or
+ * MAY_CREATE_DIR are set. That way, file systems that don't support these
+ * permissions will check for MAY_WRITE instead.
*/
int inode_permission(struct inode *inode, int mask)
{
@@ -2545,10 +2547,11 @@ EXPORT_SYMBOL(__check_sticky);
* 10. We don't allow removal of NFS sillyrenamed files; it's handled by
* nfs_async_unlink().
*/
-static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)
+static int may_delete(struct inode *dir, struct dentry *victim,
+ bool isdir, bool replace)
{
struct inode *inode = d_backing_inode(victim);
- int error;
+ int error, mask = MAY_WRITE | MAY_EXEC;
if (d_is_negative(victim))
return -ENOENT;
@@ -2557,7 +2560,9 @@ static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)
BUG_ON(victim->d_parent->d_inode != dir);
audit_inode_child(dir, victim, AUDIT_TYPE_CHILD_DELETE);
- error = inode_permission(dir, MAY_WRITE | MAY_EXEC);
+ if (replace)
+ mask |= isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE;
+ error = inode_permission(dir, mask);
if (error)
return error;
if (IS_APPEND(dir))
@@ -2588,14 +2593,16 @@ static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)
* 3. We should have write and exec permissions on dir
* 4. We can't do it if dir is immutable (done in permission())
*/
-static inline int may_create(struct inode *dir, struct dentry *child)
+static inline int may_create(struct inode *dir, struct dentry *child, bool isdir)
{
+ int mask = isdir ? MAY_CREATE_DIR : MAY_CREATE_FILE;
+
audit_inode_child(dir, child, AUDIT_TYPE_CHILD_CREATE);
if (child->d_inode)
return -EEXIST;
if (IS_DEADDIR(dir))
return -ENOENT;
- return inode_permission(dir, MAY_WRITE | MAY_EXEC);
+ return inode_permission(dir, MAY_WRITE | MAY_EXEC | mask);
}
/*
@@ -2645,7 +2652,7 @@ EXPORT_SYMBOL(unlock_rename);
int vfs_create(struct inode *dir, struct dentry *dentry, umode_t mode,
bool want_excl)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, false);
if (error)
return error;
@@ -3490,7 +3497,7 @@ EXPORT_SYMBOL(user_path_create);
int vfs_mknod(struct inode *dir, struct dentry *dentry, umode_t mode, dev_t dev)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, false);
if (error)
return error;
@@ -3582,7 +3589,7 @@ SYSCALL_DEFINE3(mknod, const char __user *, filename, umode_t, mode, unsigned, d
int vfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, true);
unsigned max_links = dir->i_sb->s_max_links;
if (error)
@@ -3663,7 +3670,7 @@ EXPORT_SYMBOL(dentry_unhash);
int vfs_rmdir(struct inode *dir, struct dentry *dentry)
{
- int error = may_delete(dir, dentry, 1);
+ int error = may_delete(dir, dentry, true, false);
if (error)
return error;
@@ -3785,7 +3792,7 @@ SYSCALL_DEFINE1(rmdir, const char __user *, pathname)
int vfs_unlink(struct inode *dir, struct dentry *dentry, struct inode **delegated_inode)
{
struct inode *target = dentry->d_inode;
- int error = may_delete(dir, dentry, 0);
+ int error = may_delete(dir, dentry, false, false);
if (error)
return error;
@@ -3919,7 +3926,7 @@ SYSCALL_DEFINE1(unlink, const char __user *, pathname)
int vfs_symlink(struct inode *dir, struct dentry *dentry, const char *oldname)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, false);
if (error)
return error;
@@ -4002,7 +4009,7 @@ int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_de
if (!inode)
return -ENOENT;
- error = may_create(dir, new_dentry);
+ error = may_create(dir, new_dentry, false);
if (error)
return error;
@@ -4190,19 +4197,19 @@ int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
if (source == target)
return 0;
- error = may_delete(old_dir, old_dentry, is_dir);
+ error = may_delete(old_dir, old_dentry, is_dir, false);
if (error)
return error;
if (!target) {
- error = may_create(new_dir, new_dentry);
+ error = may_create(new_dir, new_dentry, is_dir);
} else {
new_is_dir = d_is_dir(new_dentry);
if (!(flags & RENAME_EXCHANGE))
- error = may_delete(new_dir, new_dentry, is_dir);
+ error = may_delete(new_dir, new_dentry, is_dir, true);
else
- error = may_delete(new_dir, new_dentry, new_is_dir);
+ error = may_delete(new_dir, new_dentry, new_is_dir, true);
}
if (error)
return error;
@@ -4465,7 +4472,7 @@ SYSCALL_DEFINE2(rename, const char __user *, oldname, const char __user *, newna
int vfs_whiteout(struct inode *dir, struct dentry *dentry)
{
- int error = may_create(dir, dentry);
+ int error = may_create(dir, dentry, false);
if (error)
return error;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 4efa435..d6e2330 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -82,6 +82,8 @@ typedef void (dax_iodone_t)(struct buffer_head *bh_map, int uptodate);
#define MAY_CHDIR 0x00000040
/* called from RCU mode, don't block */
#define MAY_NOT_BLOCK 0x00000080
+#define MAY_CREATE_FILE 0x00000100
+#define MAY_CREATE_DIR 0x00000200
/*
* flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "J. Bruce Fields" <bfields@fieldses.org> |
|---|---|
| Date | 2015-09-28 18:40 +0200 |
| Message-ID | <qdJD3-4SO-1@gated-at.bofh.it> |
| In reply to | #1233752 |
On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote:
> here's another update of the richacl patch queue. At this stage, I would
> like to ask for final feedback so that the core and ext4 code (patches
> 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should
> then go through the respective maintainer trees.
I've been over the core richacl and nfsd parts very carefully, and they
definitely look ready to me.
> Changes since the last posting (https://lwn.net/Articles/656704/):
>
> * The MAY_DELETE_SELF permission now also overrides the sticky
> directory checks.
>
> * Fix the permission check algorithm to apply the owner mask instead
> of the group mask to user entries matching the current owner. That way,
> the owner will retain the permissions in those entries when creating
> objects with create mode 0700 and similar. (A chmod to mode 0700 already
> creates an owner@:rwpx::allow ace, which was hiding this bug.)
>
> * Fix richacl_apply_masks to properly insert deny aces when raising the
> permissions of the other class. The bug could be triggered by
> chmod'ing a group@:r::allow acl to mode 0077, for example.
>
> * Various cleanups and improvements to comments.
>
>
> The complete patch queue is available here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux-richacl.git \
> richacl-2015-09-28
>
>
> The richacl user-space utilitites and test suite are available here:
>
> https://github.com/andreas-gruenbacher/richacl/
>
>
> Open issues in nfs:
>
> * When a user or group name cannot be mapped, nfs's idmapper always maps it
> to nobody. That's good enough for mapping the file owner and owning
> group, but not for identifiers in acls. For now, to get the nfs richacl
> support somewhat working, I'm explicitly checking if mapping has resulted
> in uid/gid 99 in the kernel.
>
> * When the nfs server replies with NFS4ERR_BADNAME for any user or group
> name lookup, the client will stop sending numeric uids and gids to the
> server even when the lookup wasn't numeric. From then on, the client
> will translate uids and gids that have no mapping to the string "nobody",
> and the server will reject them. This problem is not specific to acls.
Do you have fixes in mind for these two issues?
--b.
>
> Thanks,
> Andreas
>
> Andreas Gruenbacher (39):
> vfs: Add IS_ACL() and IS_RICHACL() tests
> vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags
> vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags
> vfs: Make the inode passed to inode_change_ok non-const
> vfs: Add permission flags for setting file attributes
> richacl: In-memory representation and helper functions
> richacl: Permission mapping functions
> richacl: Compute maximum file masks from an acl
> richacl: Update the file masks in chmod()
> richacl: Permission check algorithm
> vfs: Cache base_acl objects in inodes
> vfs: Cache richacl in struct inode
> richacl: Check if an acl is equivalent to a file mode
> richacl: Create-time inheritance
> richacl: Automatic Inheritance
> richacl: xattr mapping functions
> vfs: Add richacl permission checking
> richacl: acl editing helper functions
> richacl: Move everyone@ aces down the acl
> richacl: Propagate everyone@ permissions to other aces
> richacl: Set the owner permissions to the owner mask
> richacl: Set the other permissions to the other mask
> richacl: Isolate the owner and group classes
> richacl: Apply the file masks to a richacl
> richacl: Create richacl from mode values
> nfsd: Keep list of acls to dispose of in compoundargs
> nfsd: Use richacls as internal acl representation
> nfsd: Add richacl support
> nfsd: Add support for the v4.1 dacl attribute
> nfsd: Add support for the MAY_CREATE_{FILE,DIR} permissions
> richacl: Add support for unmapped identifiers
> ext4: Don't allow unmapped identifiers in richacls
> sunrpc: Allow to demand-allocate pages to encode into
> sunrpc: Add xdr_init_encode_pages
> nfs: Fix GETATTR bitmap verification
> nfs: Remove unused xdr page offsets in getacl/setacl arguments
> nfs: Add richacl support
> nfs: Add support for the v4.1 dacl attribute
> richacl: uapi header split
>
> Aneesh Kumar K.V (2):
> ext4: Add richacl support
> ext4: Add richacl feature flag
>
> drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
> fs/Kconfig | 9 +
> fs/Makefile | 3 +
> fs/attr.c | 81 ++-
> fs/ext4/Kconfig | 15 +
> fs/ext4/Makefile | 1 +
> fs/ext4/acl.c | 6 +-
> fs/ext4/acl.h | 12 +-
> fs/ext4/ext4.h | 6 +-
> fs/ext4/file.c | 6 +-
> fs/ext4/ialloc.c | 7 +-
> fs/ext4/inode.c | 10 +-
> fs/ext4/namei.c | 11 +-
> fs/ext4/richacl.c | 218 ++++++
> fs/ext4/richacl.h | 47 ++
> fs/ext4/super.c | 42 +-
> fs/ext4/xattr.c | 6 +
> fs/ext4/xattr.h | 1 +
> fs/f2fs/acl.c | 4 +-
> fs/inode.c | 15 +-
> fs/jffs2/acl.c | 6 +-
> fs/namei.c | 111 ++-
> fs/nfs/inode.c | 3 -
> fs/nfs/nfs4proc.c | 701 +++++++++++++-----
> fs/nfs/nfs4xdr.c | 257 ++++++-
> fs/nfs/super.c | 4 +-
> fs/nfs_common/Makefile | 1 +
> fs/nfs_common/nfs4acl.c | 44 ++
> fs/nfsd/Kconfig | 1 +
> fs/nfsd/acl.h | 23 +-
> fs/nfsd/nfs4acl.c | 482 +++++++------
> fs/nfsd/nfs4proc.c | 25 +-
> fs/nfsd/nfs4xdr.c | 268 ++++---
> fs/nfsd/nfsd.h | 6 +-
> fs/nfsd/nfsfh.c | 8 +-
> fs/nfsd/vfs.c | 28 +-
> fs/nfsd/vfs.h | 17 +-
> fs/nfsd/xdr4.h | 12 +-
> fs/posix_acl.c | 26 +-
> fs/richacl_base.c | 682 ++++++++++++++++++
> fs/richacl_compat.c | 915 ++++++++++++++++++++++++
> fs/richacl_inode.c | 297 ++++++++
> fs/richacl_xattr.c | 267 +++++++
> fs/xattr.c | 34 +-
> include/linux/fs.h | 50 +-
> include/linux/nfs4.h | 24 +-
> include/linux/nfs4acl.h | 7 +
> include/linux/nfs_fs.h | 1 -
> include/linux/nfs_fs_sb.h | 2 +
> include/linux/nfs_xdr.h | 13 +-
> include/linux/posix_acl.h | 12 +-
> include/linux/richacl.h | 275 +++++++
> include/linux/richacl_compat.h | 40 ++
> include/linux/richacl_xattr.h | 47 ++
> include/linux/sunrpc/xdr.h | 2 +
> include/uapi/linux/Kbuild | 2 +
> include/uapi/linux/fs.h | 3 +-
> include/uapi/linux/nfs4.h | 3 +-
> include/uapi/linux/richacl.h | 111 +++
> include/uapi/linux/richacl_xattr.h | 43 ++
> include/uapi/linux/xattr.h | 2 +
> net/sunrpc/xdr.c | 34 +
> 62 files changed, 4659 insertions(+), 732 deletions(-)
> create mode 100644 fs/ext4/richacl.c
> create mode 100644 fs/ext4/richacl.h
> create mode 100644 fs/nfs_common/nfs4acl.c
> create mode 100644 fs/richacl_base.c
> create mode 100644 fs/richacl_compat.c
> create mode 100644 fs/richacl_inode.c
> create mode 100644 fs/richacl_xattr.c
> create mode 100644 include/linux/nfs4acl.h
> create mode 100644 include/linux/richacl.h
> create mode 100644 include/linux/richacl_compat.h
> create mode 100644 include/linux/richacl_xattr.h
> create mode 100644 include/uapi/linux/richacl.h
> create mode 100644 include/uapi/linux/richacl_xattr.h
>
> --
> 2.4.3
>
>
> Andreas Gruenbacher (39):
> vfs: Add IS_ACL() and IS_RICHACL() tests
> vfs: Add MAY_CREATE_FILE and MAY_CREATE_DIR permission flags
> vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags
> vfs: Make the inode passed to inode_change_ok non-const
> vfs: Add permission flags for setting file attributes
> richacl: In-memory representation and helper functions
> richacl: Permission mapping functions
> richacl: Compute maximum file masks from an acl
> richacl: Update the file masks in chmod()
> richacl: Permission check algorithm
> vfs: Cache base_acl objects in inodes
> vfs: Cache richacl in struct inode
> richacl: Check if an acl is equivalent to a file mode
> richacl: Create-time inheritance
> richacl: Automatic Inheritance
> richacl: xattr mapping functions
> vfs: Add richacl permission checking
> richacl: acl editing helper functions
> richacl: Move everyone@ aces down the acl
> richacl: Propagate everyone@ permissions to other aces
> richacl: Set the owner permissions to the owner mask
> richacl: Set the other permissions to the other mask
> richacl: Isolate the owner and group classes
> richacl: Apply the file masks to a richacl
> richacl: Create richacl from mode values
> nfsd: Keep list of acls to dispose of in compoundargs
> nfsd: Use richacls as internal acl representation
> nfsd: Add richacl support
> nfsd: Add support for the v4.1 dacl attribute
> nfsd: Add support for the MAY_CREATE_{FILE,DIR} permissions
> richacl: Add support for unmapped identifiers
> ext4: Don't allow unmapped identifiers in richacls
> sunrpc: Allow to demand-allocate pages to encode into
> sunrpc: Add xdr_init_encode_pages
> nfs: Fix GETATTR bitmap verification
> nfs: Remove unused xdr page offsets in getacl/setacl arguments
> nfs: Add richacl support
> nfs: Add support for the v4.1 dacl attribute
> richacl: uapi header split
>
> Aneesh Kumar K.V (2):
> ext4: Add richacl support
> ext4: Add richacl feature flag
>
> drivers/staging/lustre/lustre/llite/llite_lib.c | 2 +-
> fs/Kconfig | 9 +
> fs/Makefile | 3 +
> fs/attr.c | 81 ++-
> fs/ext4/Kconfig | 15 +
> fs/ext4/Makefile | 1 +
> fs/ext4/acl.c | 6 +-
> fs/ext4/acl.h | 12 +-
> fs/ext4/ext4.h | 6 +-
> fs/ext4/file.c | 6 +-
> fs/ext4/ialloc.c | 7 +-
> fs/ext4/inode.c | 10 +-
> fs/ext4/namei.c | 11 +-
> fs/ext4/richacl.c | 218 ++++++
> fs/ext4/richacl.h | 47 ++
> fs/ext4/super.c | 42 +-
> fs/ext4/xattr.c | 6 +
> fs/ext4/xattr.h | 1 +
> fs/f2fs/acl.c | 4 +-
> fs/inode.c | 15 +-
> fs/jffs2/acl.c | 6 +-
> fs/namei.c | 111 ++-
> fs/nfs/inode.c | 3 -
> fs/nfs/nfs4proc.c | 701 +++++++++++++-----
> fs/nfs/nfs4xdr.c | 257 ++++++-
> fs/nfs/super.c | 4 +-
> fs/nfs_common/Makefile | 1 +
> fs/nfs_common/nfs4acl.c | 44 ++
> fs/nfsd/Kconfig | 1 +
> fs/nfsd/acl.h | 23 +-
> fs/nfsd/nfs4acl.c | 482 +++++++------
> fs/nfsd/nfs4proc.c | 25 +-
> fs/nfsd/nfs4xdr.c | 268 ++++---
> fs/nfsd/nfsd.h | 6 +-
> fs/nfsd/nfsfh.c | 8 +-
> fs/nfsd/vfs.c | 28 +-
> fs/nfsd/vfs.h | 17 +-
> fs/nfsd/xdr4.h | 12 +-
> fs/posix_acl.c | 26 +-
> fs/richacl_base.c | 682 ++++++++++++++++++
> fs/richacl_compat.c | 915 ++++++++++++++++++++++++
> fs/richacl_inode.c | 297 ++++++++
> fs/richacl_xattr.c | 267 +++++++
> fs/xattr.c | 34 +-
> include/linux/fs.h | 50 +-
> include/linux/nfs4.h | 24 +-
> include/linux/nfs4acl.h | 7 +
> include/linux/nfs_fs.h | 1 -
> include/linux/nfs_fs_sb.h | 2 +
> include/linux/nfs_xdr.h | 13 +-
> include/linux/posix_acl.h | 12 +-
> include/linux/richacl.h | 275 +++++++
> include/linux/richacl_compat.h | 40 ++
> include/linux/richacl_xattr.h | 47 ++
> include/linux/sunrpc/xdr.h | 2 +
> include/uapi/linux/Kbuild | 2 +
> include/uapi/linux/fs.h | 3 +-
> include/uapi/linux/nfs4.h | 3 +-
> include/uapi/linux/richacl.h | 111 +++
> include/uapi/linux/richacl_xattr.h | 43 ++
> include/uapi/linux/xattr.h | 2 +
> net/sunrpc/xdr.c | 34 +
> 62 files changed, 4659 insertions(+), 732 deletions(-)
> create mode 100644 fs/ext4/richacl.c
> create mode 100644 fs/ext4/richacl.h
> create mode 100644 fs/nfs_common/nfs4acl.c
> create mode 100644 fs/richacl_base.c
> create mode 100644 fs/richacl_compat.c
> create mode 100644 fs/richacl_inode.c
> create mode 100644 fs/richacl_xattr.c
> create mode 100644 include/linux/nfs4acl.h
> create mode 100644 include/linux/richacl.h
> create mode 100644 include/linux/richacl_compat.h
> create mode 100644 include/linux/richacl_xattr.h
> create mode 100644 include/uapi/linux/richacl.h
> create mode 100644 include/uapi/linux/richacl_xattr.h
>
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Grünbacher <andreas.gruenbacher@gmail.com> |
|---|---|
| Date | 2015-09-28 19:20 +0200 |
| Message-ID | <qdKfM-5Rq-17@gated-at.bofh.it> |
| In reply to | #1234280 |
2015-09-28 18:35 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: >> here's another update of the richacl patch queue. At this stage, I would >> like to ask for final feedback so that the core and ext4 code (patches >> 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should >> then go through the respective maintainer trees. > > I've been over the core richacl and nfsd parts very carefully, and they > definitely look ready to me. Thanks a lot for all that work, by the way. >> Changes since the last posting (https://lwn.net/Articles/656704/): >> >> * The MAY_DELETE_SELF permission now also overrides the sticky >> directory checks. >> >> * Fix the permission check algorithm to apply the owner mask instead >> of the group mask to user entries matching the current owner. That way, >> the owner will retain the permissions in those entries when creating >> objects with create mode 0700 and similar. (A chmod to mode 0700 already >> creates an owner@:rwpx::allow ace, which was hiding this bug.) >> >> * Fix richacl_apply_masks to properly insert deny aces when raising the >> permissions of the other class. The bug could be triggered by >> chmod'ing a group@:r::allow acl to mode 0077, for example. >> >> * Various cleanups and improvements to comments. >> >> >> The complete patch queue is available here: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux-richacl.git \ >> richacl-2015-09-28 >> >> >> The richacl user-space utilitites and test suite are available here: >> >> https://github.com/andreas-gruenbacher/richacl/ >> >> >> Open issues in nfs: >> >> * When a user or group name cannot be mapped, nfs's idmapper always maps it >> to nobody. That's good enough for mapping the file owner and owning >> group, but not for identifiers in acls. For now, to get the nfs richacl >> support somewhat working, I'm explicitly checking if mapping has resulted >> in uid/gid 99 in the kernel. >> >> * When the nfs server replies with NFS4ERR_BADNAME for any user or group >> name lookup, the client will stop sending numeric uids and gids to the >> server even when the lookup wasn't numeric. From then on, the client >> will translate uids and gids that have no mapping to the string "nobody", >> and the server will reject them. This problem is not specific to acls. > > Do you have fixes in mind for these two issues? I'm not sure how to best fix the idmapper problem, with backwards compatibility and all. The second problem shouldn't be too hard to fix. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "J. Bruce Fields" <bfields@fieldses.org> |
|---|---|
| Date | 2015-09-28 19:50 +0200 |
| Message-ID | <qdKIO-6p5-5@gated-at.bofh.it> |
| In reply to | #1234309 |
On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote: > 2015-09-28 18:35 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: > > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > >> Open issues in nfs: > >> > >> * When a user or group name cannot be mapped, nfs's idmapper always maps it > >> to nobody. That's good enough for mapping the file owner and owning > >> group, but not for identifiers in acls. For now, to get the nfs richacl > >> support somewhat working, I'm explicitly checking if mapping has resulted > >> in uid/gid 99 in the kernel. > >> > >> * When the nfs server replies with NFS4ERR_BADNAME for any user or group > >> name lookup, the client will stop sending numeric uids and gids to the > >> server even when the lookup wasn't numeric. From then on, the client > >> will translate uids and gids that have no mapping to the string "nobody", > >> and the server will reject them. This problem is not specific to acls. > > > > Do you have fixes in mind for these two issues? > > I'm not sure how to best fix the idmapper problem, with backwards > compatibility and all. I haven't looked at the current nfsidmap interface.... So it's completely lacking any way to communicate failure? > The second problem shouldn't be too hard to fix. Is it enough to turn off the failover in the case there's no possibility it could have been caused by a numeric id? If any user can set ACLs with arbitrary strings as names, then we'd be giving any user unprivileged user the ability to turn off numeric idmapping, so I think we need to fix that. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Grünbacher <andreas.gruenbacher@gmail.com> |
|---|---|
| Date | 2015-09-29 17:00 +0200 |
| Message-ID | <qe4xP-1b4-5@gated-at.bofh.it> |
| In reply to | #1234324 |
2015-09-28 19:46 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: > On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote: >> 2015-09-28 18:35 GMT+02:00 J. Bruce Fields <bfields@fieldses.org>: >> > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: >> >> Open issues in nfs: >> >> >> >> * When a user or group name cannot be mapped, nfs's idmapper always maps it >> >> to nobody. That's good enough for mapping the file owner and owning >> >> group, but not for identifiers in acls. For now, to get the nfs richacl >> >> support somewhat working, I'm explicitly checking if mapping has resulted >> >> in uid/gid 99 in the kernel. >> >> >> >> * When the nfs server replies with NFS4ERR_BADNAME for any user or group >> >> name lookup, the client will stop sending numeric uids and gids to the >> >> server even when the lookup wasn't numeric. From then on, the client >> >> will translate uids and gids that have no mapping to the string "nobody", >> >> and the server will reject them. This problem is not specific to acls. >> > >> > Do you have fixes in mind for these two issues? >> >> I'm not sure how to best fix the idmapper problem, with backwards >> compatibility and all. > > I haven't looked at the current nfsidmap interface.... So it's > completely lacking any way to communicate failure? Yes, when a user doesn't exist, idmapper maps that to the nobody uid/gid. That's the failure mode of stat. In the acl case, we do want to map user and group names to their respective ids where possible (so that the acl makes sense in the local system context), but we do want to preserve the original user and group names when there is no such mapping instead of mapping to the nobody uid/gid. >> The second problem shouldn't be too hard to fix. > > Is it enough to turn off the failover in the case there's no possibility > it could have been caused by a numeric id? Yes, I believe that would be enough. > If any user can set ACLs with arbitrary strings as names, then we'd be > giving any user unprivileged user the ability to turn off numeric > idmapping, so I think we need to fix that. The bug can be triggered by unprivileged users with nfs4_setfacl. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Christoph Hellwig <hch@infradead.org> |
|---|---|
| Date | 2015-10-04 08:30 +0200 |
| Message-ID | <qfKY1-FS-1@gated-at.bofh.it> |
| In reply to | #1233752 |
On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > Hello, > > here's another update of the richacl patch queue. At this stage, I would > like to ask for final feedback so that the core and ext4 code (patches > 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should > then go through the respective maintainer trees. Now way in this form even if everyone agrees we should have these bastard ACLs. I certainly disagree. Ayway, back to the VFS <-> FS interface. You still require tons of boilderplate code in the filesystem which isn't required and we got rid of for Posix ACLs. The filesystem should not look at the userspace xattr format, please follow a model similar to ->get_acl and ->set_acl for Posix ACLs. After that the wire up should be so trivial that you can wire up btrfs, xfs and f2fs as well, which is important to make the feature mergeable. And honestly I tink adding even more overload to xattrs is a really bad idea and after 10 years of experience with that junk we really need to learn and make new overloads proper system calls. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2015-10-05 20:50 +0200 |
| Message-ID | <qgiZH-7ez-13@gated-at.bofh.it> |
| In reply to | #1239041 |
On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote: > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: >> Hello, >> >> here's another update of the richacl patch queue. At this stage, I would >> like to ask for final feedback so that the core and ext4 code (patches >> 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should >> then go through the respective maintainer trees. > > Now way in this form even if everyone agrees we should have these > bastard ACLs. I certainly disagree. Well, thanks for having a look at the patches. > Ayway, back to the VFS <-> FS interface. You still require tons of > boilderplate code in the filesystem which isn't required and we got rid > of for Posix ACLs. The filesystem should not look at the userspace > xattr format, please follow a model similar to ->get_acl and ->set_acl > for Posix ACLs. I will repost a version that has this cleaned up. > After that the wire up should be so trivial that you can wire up btrfs, > xfs and f2fs as well, which is important to make the feature mergeable. Why would the patch queue become more mergeable by having support for more filesystems in it? The filesystem specific code really isn't all that interesting. > And honestly I tink adding even more overload to xattrs is a really bad > idea and after 10 years of experience with that junk we really need to > learn and make new overloads proper system calls. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-10-05 21:00 +0200 |
| Message-ID | <qgj9p-7qa-19@gated-at.bofh.it> |
| In reply to | #1239839 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-10-05 14:45, Andreas Gruenbacher wrote: > On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote: >> On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: >>> Hello, >>> >>> here's another update of the richacl patch queue. At this stage, I would >>> like to ask for final feedback so that the core and ext4 code (patches >>> 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should >>> then go through the respective maintainer trees. >> >> Now way in this form even if everyone agrees we should have these >> bastard ACLs. I certainly disagree. > > Well, thanks for having a look at the patches. > >> Ayway, back to the VFS <-> FS interface. You still require tons of >> boilderplate code in the filesystem which isn't required and we got rid >> of for Posix ACLs. The filesystem should not look at the userspace >> xattr format, please follow a model similar to ->get_acl and ->set_acl >> for Posix ACLs. > > I will repost a version that has this cleaned up. > >> After that the wire up should be so trivial that you can wire up btrfs, >> xfs and f2fs as well, which is important to make the feature mergeable. > > Why would the patch queue become more mergeable by having support for > more filesystems in it? The filesystem specific code really isn't all > that interesting. I think the point is that a new VFS feature that is easy to integrate in multiple filesystems should have support for those filesystems. A decade ago, just having ext* support would probably have been fine, but these days, XFS, BTRFS, and F2FS are used just as much (if not more) on production systems as ext4, and having support for them right from the start would significantly help with adoption of richacls. > >> And honestly I tink adding even more overload to xattrs is a really bad >> idea and after 10 years of experience with that junk we really need to >> learn and make new overloads proper system calls. > > Thanks, > Andreas > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
[toc] | [prev] | [next] | [standalone]
| From | Dave Chinner <david@fromorbit.com> |
|---|---|
| Date | 2015-10-05 23:20 +0200 |
| Message-ID | <qglkS-2ny-17@gated-at.bofh.it> |
| In reply to | #1239839 |
On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote: > On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote: > > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: > >> Hello, > >> > >> here's another update of the richacl patch queue. At this stage, I would > >> like to ask for final feedback so that the core and ext4 code (patches > >> 1-19) can be merged in the 4.4 merge window. The nfsd and nfs code should > >> then go through the respective maintainer trees. > > > > Now way in this form even if everyone agrees we should have these > > bastard ACLs. I certainly disagree. > > Well, thanks for having a look at the patches. > > > Ayway, back to the VFS <-> FS interface. You still require tons of > > boilderplate code in the filesystem which isn't required and we got rid > > of for Posix ACLs. The filesystem should not look at the userspace > > xattr format, please follow a model similar to ->get_acl and ->set_acl > > for Posix ACLs. > > I will repost a version that has this cleaned up. > > > After that the wire up should be so trivial that you can wire up btrfs, > > xfs and f2fs as well, which is important to make the feature mergeable. > > Why would the patch queue become more mergeable by having support for > more filesystems in it? The filesystem specific code really isn't all > that interesting. The hardest part for the filesystem support is the on-disk feature flag that needs to be set. The kernel part of that is easy, but it's an on-disk format change and so there's also all the userspace side for mkfs, fsck, debug tools, etc, that also need to be able to parse and understand it. So while the xattr code can be made much more generic, there's a bunch of filesystem specific code that needs to go into multiple different repositories and userspace packages for this. Andreas, I also can't remember if any xfstests have been written for these ACLs? That would certainly help make sure all these filesystems have equivalent behaviour... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2015-10-06 00:10 +0200 |
| Message-ID | <qgm7h-3xT-25@gated-at.bofh.it> |
| In reply to | #1239975 |
On Mon, Oct 5, 2015 at 11:17 PM, Dave Chinner <david@fromorbit.com> wrote: > On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote: >> On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig <hch@infradead.org> wrote: >> > After that the wire up should be so trivial that you can wire up btrfs, >> > xfs and f2fs as well, which is important to make the feature mergeable. >> >> Why would the patch queue become more mergeable by having support for >> more filesystems in it? The filesystem specific code really isn't all >> that interesting. > > The hardest part for the filesystem support is the on-disk feature > flag that needs to be set. The kernel part of that is easy, but it's > an on-disk format change and so there's also all the userspace side > for mkfs, fsck, debug tools, etc, that also need to be able to parse > and understand it. So while the xattr code can be made much more > generic, there's a bunch of filesystem specific code that needs to > go into multiple different repositories and userspace packages for > this. Yes. > Andreas, I also can't remember if any xfstests have been written for > these ACLs? That would certainly help make sure all these > filesystems have equivalent behaviour... There's a reasonable amount of tests in the richacl user-space package which are shell based, with a few small C helpers. We could move those into xfstests eventually; now seems a bit early to me. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web