From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: sfrench@us.ibm.com, ffilz@us.ibm.com, agruen@suse.de,
adilger@sun.com, sandeen@redhat.com, tytso@mit.edu,
bfields@citi.umich.edu, jlayton@redhat.com
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org
Subject: [PATCH -V3 10/17] richacl: Create-time inheritance
Date: Thu, 29 Jul 2010 23:27:48 +0530 [thread overview]
Message-ID: <1280426275-4602-11-git-send-email-aneesh.kumar@linux.vnet.ibm.com> (raw)
In-Reply-To: <1280426275-4602-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
From: Andreas Gruenbacher <agruen@suse.de>
When a new file is created, it can inherit an acl from its parent
directory; this is similar to how default acls work in POSIX (draft)
ACLs.
As with POSIX ACLs, if a file inherits an acl from its parent directory,
the intersection between the create mode and the permissions granted by
the inherited acl determines the file masks and file permission bits,
and the umask is ignored.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
fs/richacl_base.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++
fs/richacl_inode.c | 40 +++++++++++++++++++++++++++
include/linux/richacl.h | 3 ++
3 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/fs/richacl_base.c b/fs/richacl_base.c
index b91dec3..6074116 100644
--- a/fs/richacl_base.c
+++ b/fs/richacl_base.c
@@ -472,3 +472,72 @@ is_everyone:
return denied ? -EACCES : 0;
}
EXPORT_SYMBOL_GPL(richacl_permission);
+
+/**
+ * richacl_inherit - compute the inherited acl of a new file
+ * @dir_acl: acl of the containing direcory
+ * @isdir: inherit by a directory or non-directory?
+ *
+ * A directory can have acl entries which files and/or directories created
+ * inside the directory will inherit. This function computes the acl for such
+ * a new file. If there is no inheritable acl, it will return %NULL.
+ */
+struct richacl *
+richacl_inherit(const struct richacl *dir_acl, int isdir)
+{
+ const struct richace *dir_ace;
+ struct richacl *acl = NULL;
+ struct richace *ace;
+ int count = 0;
+
+ if (isdir) {
+ richacl_for_each_entry(dir_ace, dir_acl) {
+ if (!richace_is_inheritable(dir_ace))
+ continue;
+ count++;
+ }
+ if (!count)
+ return NULL;
+ acl = richacl_alloc(count);
+ if (!acl)
+ return ERR_PTR(-ENOMEM);
+ ace = acl->a_entries;
+ richacl_for_each_entry(dir_ace, dir_acl) {
+ if (!richace_is_inheritable(dir_ace))
+ continue;
+ memcpy(ace, dir_ace, sizeof(struct richace));
+ if (dir_ace->e_flags & ACE4_NO_PROPAGATE_INHERIT_ACE)
+ richace_clear_inheritance_flags(ace);
+ if ((dir_ace->e_flags & ACE4_FILE_INHERIT_ACE) &&
+ !(dir_ace->e_flags & ACE4_DIRECTORY_INHERIT_ACE))
+ ace->e_flags |= ACE4_INHERIT_ONLY_ACE;
+ ace++;
+ }
+ } else {
+ richacl_for_each_entry(dir_ace, dir_acl) {
+ if (!(dir_ace->e_flags & ACE4_FILE_INHERIT_ACE))
+ continue;
+ count++;
+ }
+ if (!count)
+ return NULL;
+ acl = richacl_alloc(count);
+ if (!acl)
+ return ERR_PTR(-ENOMEM);
+ ace = acl->a_entries;
+ richacl_for_each_entry(dir_ace, dir_acl) {
+ if (!(dir_ace->e_flags & ACE4_FILE_INHERIT_ACE))
+ continue;
+ memcpy(ace, dir_ace, sizeof(struct richace));
+ richace_clear_inheritance_flags(ace);
+ /*
+ * ACE4_DELETE_CHILD is meaningless for
+ * non-directories, so clear it.
+ */
+ ace->e_mask &= ~ACE4_DELETE_CHILD;
+ ace++;
+ }
+ }
+
+ return acl;
+}
diff --git a/fs/richacl_inode.c b/fs/richacl_inode.c
index 9e80b33..f5dd95a 100644
--- a/fs/richacl_inode.c
+++ b/fs/richacl_inode.c
@@ -193,3 +193,43 @@ error:
return -EPERM;
}
EXPORT_SYMBOL_GPL(richacl_inode_change_ok);
+
+/**
+ * richacl_inherit_inode - compute inherited acl and file mode
+ * @dir_acl: acl of the containing direcory
+ * @inode: inode of the new file (create mode in i_mode)
+ *
+ * The file permission bits in inode->i_mode must be set to the create mode.
+ * If there is an inheritable acl, the maximum permissions that the acl grants
+ * will be computed and permissions not granted by the acl will be removed from
+ * inode->i_mode. If there is no inheritable acl, the umask will be applied
+ * instead.
+ */
+struct richacl *
+richacl_inherit_inode(const struct richacl *dir_acl, struct inode *inode)
+{
+ struct richacl *acl;
+ mode_t mask;
+
+ acl = richacl_inherit(dir_acl, S_ISDIR(inode->i_mode));
+ if (acl) {
+
+ richacl_compute_max_masks(acl);
+
+ /*
+ * Ensure that the acl will not grant any permissions beyond
+ * the create mode.
+ */
+ acl->a_flags |= ACL4_MASKED;
+ acl->a_owner_mask &= richacl_mode_to_mask(inode->i_mode >> 6) |
+ ACE4_POSIX_OWNER_ALLOWED;
+ acl->a_group_mask &= richacl_mode_to_mask(inode->i_mode >> 3);
+ acl->a_other_mask &= richacl_mode_to_mask(inode->i_mode);
+ mask = ~S_IRWXUGO | richacl_masks_to_mode(acl);
+ } else
+ mask = ~current_umask();
+
+ inode->i_mode &= mask;
+ return acl;
+}
+EXPORT_SYMBOL_GPL(richacl_inherit_inode);
diff --git a/include/linux/richacl.h b/include/linux/richacl.h
index f6f892d..05d2319 100644
--- a/include/linux/richacl.h
+++ b/include/linux/richacl.h
@@ -291,6 +291,7 @@ extern void richacl_compute_max_masks(struct richacl *);
extern struct richacl *richacl_chmod(struct richacl *, mode_t);
extern int richacl_permission(struct inode *, const struct richacl *,
unsigned int);
+extern struct richacl *richacl_inherit(const struct richacl *, int);
/* richacl_inode.c */
@@ -303,6 +304,8 @@ extern int richacl_inode_permission(struct inode *, const struct richacl *,
unsigned int);
extern int richacl_inode_change_ok(struct inode *, struct iattr *,
int (*)(struct inode *, unsigned int));
+extern struct richacl *richacl_inherit_inode(const struct richacl *,
+ struct inode *);
#else
static inline int
richacl_inode_change_ok(struct inode *inode, struct iattr *attr,
--
1.7.0.4
_______________________________________________
NOTE: THIS LIST IS DEPRECATED. Please use linux-nfs@vger.kernel.org instead.
(To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org.)
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
next prev parent reply other threads:[~2010-07-29 17:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-29 17:57 [PATCH -V3 00/17] New ACL format for better NFSv4 acl Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 01/17] vfs: Hooks for more fine-grained directory permission checking Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 02/17] vfs: Add generic IS_ACL() test for acl support Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 03/17] vfs: Add IS_RICHACL() test for richacl support Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 04/17] richacl: In-memory representation and helper functions Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 05/17] richacl: Permission mapping functions Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 06/17] richacl: Compute maximum file masks from an acl Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 07/17] richacl: Update the file masks in chmod() Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 08/17] richacl: Permission check algorithm Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 09/17] richacl: Helper functions for implementing richacl inode operations Aneesh Kumar K.V
2010-07-29 17:57 ` Aneesh Kumar K.V [this message]
2010-07-29 17:57 ` [PATCH -V3 11/17] richacl: Check if an acl is equivalent to a file mode Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 12/17] richacl: Automatic Inheritance Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 13/17] richacl: xattr mapping functions Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 14/17] ext4: Use IS_POSIXACL() to check for POSIX ACL support Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 15/17] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 16/17] vfs: Cache richacl in struct inode Aneesh Kumar K.V
2010-07-29 17:57 ` [PATCH -V3 17/17] ext4: Add temporary richacl mount option for ext4 Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1280426275-4602-11-git-send-email-aneesh.kumar@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=adilger@sun.com \
--cc=agruen@suse.de \
--cc=bfields@citi.umich.edu \
--cc=ffilz@us.ibm.com \
--cc=jlayton@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=sandeen@redhat.com \
--cc=sfrench@us.ibm.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).