2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Common NFSv4 ACL handling code.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2002, 2003 The Regents of the University of Michigan.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Marius Aamodt Eriksen <marius@umich.edu>
|
|
|
|
* Jeff Sedlak <jsedlak@umich.edu>
|
|
|
|
* J. Bruce Fields <bfields@umich.edu>
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. Neither the name of the University nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived
|
|
|
|
* from this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
|
|
|
|
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
|
|
|
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
|
|
* DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
|
|
|
|
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
|
|
|
|
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
|
|
|
|
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
|
|
|
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/nfs_fs.h>
|
2013-12-20 13:16:55 +00:00
|
|
|
#include "nfsfh.h"
|
2014-01-08 14:49:01 +00:00
|
|
|
#include "nfsd.h"
|
2011-01-04 22:37:15 +00:00
|
|
|
#include "acl.h"
|
2013-12-20 13:16:55 +00:00
|
|
|
#include "vfs.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
#define NFS4_ACL_TYPE_DEFAULT 0x01
|
|
|
|
#define NFS4_ACL_DIR 0x02
|
|
|
|
#define NFS4_ACL_OWNER 0x04
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* mode bit translations: */
|
|
|
|
#define NFS4_READ_MODE (NFS4_ACE_READ_DATA)
|
|
|
|
#define NFS4_WRITE_MODE (NFS4_ACE_WRITE_DATA | NFS4_ACE_APPEND_DATA)
|
|
|
|
#define NFS4_EXECUTE_MODE NFS4_ACE_EXECUTE
|
|
|
|
#define NFS4_ANYONE_MODE (NFS4_ACE_READ_ATTRIBUTES | NFS4_ACE_READ_ACL | NFS4_ACE_SYNCHRONIZE)
|
|
|
|
#define NFS4_OWNER_MODE (NFS4_ACE_WRITE_ATTRIBUTES | NFS4_ACE_WRITE_ACL)
|
|
|
|
|
|
|
|
/* We don't support these bits; insist they be neither allowed nor denied */
|
|
|
|
#define NFS4_MASK_UNSUPP (NFS4_ACE_DELETE | NFS4_ACE_WRITE_OWNER \
|
|
|
|
| NFS4_ACE_READ_NAMED_ATTRS | NFS4_ACE_WRITE_NAMED_ATTRS)
|
|
|
|
|
|
|
|
/* flags used to simulate posix default ACLs */
|
|
|
|
#define NFS4_INHERITANCE_FLAGS (NFS4_ACE_FILE_INHERIT_ACE \
|
2007-02-16 09:28:28 +00:00
|
|
|
| NFS4_ACE_DIRECTORY_INHERIT_ACE)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-02-16 09:28:28 +00:00
|
|
|
#define NFS4_SUPPORTED_FLAGS (NFS4_INHERITANCE_FLAGS \
|
|
|
|
| NFS4_ACE_INHERIT_ONLY_ACE \
|
|
|
|
| NFS4_ACE_IDENTIFIER_GROUP)
|
2006-10-04 09:16:12 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#define MASK_EQUAL(mask1, mask2) \
|
|
|
|
( ((mask1) & NFS4_ACE_MASK_ALL) == ((mask2) & NFS4_ACE_MASK_ALL) )
|
|
|
|
|
|
|
|
static u32
|
|
|
|
mask_from_posix(unsigned short perm, unsigned int flags)
|
|
|
|
{
|
|
|
|
int mask = NFS4_ANYONE_MODE;
|
|
|
|
|
|
|
|
if (flags & NFS4_ACL_OWNER)
|
|
|
|
mask |= NFS4_OWNER_MODE;
|
|
|
|
if (perm & ACL_READ)
|
|
|
|
mask |= NFS4_READ_MODE;
|
|
|
|
if (perm & ACL_WRITE)
|
|
|
|
mask |= NFS4_WRITE_MODE;
|
|
|
|
if ((perm & ACL_WRITE) && (flags & NFS4_ACL_DIR))
|
|
|
|
mask |= NFS4_ACE_DELETE_CHILD;
|
|
|
|
if (perm & ACL_EXECUTE)
|
|
|
|
mask |= NFS4_EXECUTE_MODE;
|
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u32
|
2007-02-16 09:28:36 +00:00
|
|
|
deny_mask_from_posix(unsigned short perm, u32 flags)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-02-16 09:28:36 +00:00
|
|
|
u32 mask = 0;
|
|
|
|
|
|
|
|
if (perm & ACL_READ)
|
|
|
|
mask |= NFS4_READ_MODE;
|
|
|
|
if (perm & ACL_WRITE)
|
|
|
|
mask |= NFS4_WRITE_MODE;
|
|
|
|
if ((perm & ACL_WRITE) && (flags & NFS4_ACL_DIR))
|
|
|
|
mask |= NFS4_ACE_DELETE_CHILD;
|
|
|
|
if (perm & ACL_EXECUTE)
|
|
|
|
mask |= NFS4_EXECUTE_MODE;
|
|
|
|
return mask;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* XXX: modify functions to return NFS errors; they're only ever
|
|
|
|
* used by nfs code, after all.... */
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
/* We only map from NFSv4 to POSIX ACLs when setting ACLs, when we err on the
|
|
|
|
* side of being more restrictive, so the mode bit mapping below is
|
|
|
|
* pessimistic. An optimistic version would be needed to handle DENY's,
|
|
|
|
* but we espect to coalesce all ALLOWs and DENYs before mapping to mode
|
|
|
|
* bits. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
low_mode_from_nfs4(u32 perm, unsigned short *mode, unsigned int flags)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
u32 write_mode = NFS4_WRITE_MODE;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
if (flags & NFS4_ACL_DIR)
|
|
|
|
write_mode |= NFS4_ACE_DELETE_CHILD;
|
2005-04-16 22:20:36 +00:00
|
|
|
*mode = 0;
|
|
|
|
if ((perm & NFS4_READ_MODE) == NFS4_READ_MODE)
|
|
|
|
*mode |= ACL_READ;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
if ((perm & write_mode) == write_mode)
|
2005-04-16 22:20:36 +00:00
|
|
|
*mode |= ACL_WRITE;
|
|
|
|
if ((perm & NFS4_EXECUTE_MODE) == NFS4_EXECUTE_MODE)
|
|
|
|
*mode |= ACL_EXECUTE;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct ace_container {
|
|
|
|
struct nfs4_ace *ace;
|
|
|
|
struct list_head ace_l;
|
|
|
|
};
|
|
|
|
|
|
|
|
static short ace2type(struct nfs4_ace *);
|
2007-02-16 09:28:30 +00:00
|
|
|
static void _posix_to_nfsv4_one(struct posix_acl *, struct nfs4_acl *,
|
|
|
|
unsigned int);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
int
|
|
|
|
nfsd4_get_nfs4_acl(struct svc_rqst *rqstp, struct dentry *dentry,
|
|
|
|
struct nfs4_acl **acl)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-12-20 13:16:55 +00:00
|
|
|
struct inode *inode = dentry->d_inode;
|
|
|
|
int error = 0;
|
|
|
|
struct posix_acl *pacl = NULL, *dpacl = NULL;
|
|
|
|
unsigned int flags = 0;
|
2007-02-16 09:28:30 +00:00
|
|
|
int size = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
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);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-02-11 16:29:05 +00:00
|
|
|
/* allocate for worst case: one (deny, allow) pair each: */
|
|
|
|
size += 2 * pacl->a_count;
|
2013-12-20 13:16:55 +00:00
|
|
|
|
|
|
|
if (S_ISDIR(inode->i_mode)) {
|
|
|
|
flags = NFS4_ACL_DIR;
|
|
|
|
dpacl = get_acl(inode, ACL_TYPE_DEFAULT);
|
|
|
|
if (dpacl)
|
|
|
|
size += 2 * dpacl->a_count;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
*acl = nfs4_acl_new(size);
|
|
|
|
if (*acl == NULL) {
|
|
|
|
error = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-02-11 16:29:05 +00:00
|
|
|
_posix_to_nfsv4_one(pacl, *acl, flags & ~NFS4_ACL_TYPE_DEFAULT);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-02-16 09:28:30 +00:00
|
|
|
if (dpacl)
|
2013-12-20 13:16:55 +00:00
|
|
|
_posix_to_nfsv4_one(dpacl, *acl, flags | NFS4_ACL_TYPE_DEFAULT);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
out:
|
|
|
|
posix_acl_release(pacl);
|
|
|
|
posix_acl_release(dpacl);
|
|
|
|
return error;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2007-02-16 09:28:36 +00:00
|
|
|
struct posix_acl_summary {
|
|
|
|
unsigned short owner;
|
|
|
|
unsigned short users;
|
|
|
|
unsigned short group;
|
|
|
|
unsigned short groups;
|
|
|
|
unsigned short other;
|
|
|
|
unsigned short mask;
|
|
|
|
};
|
|
|
|
|
2007-02-16 09:28:30 +00:00
|
|
|
static void
|
2007-02-16 09:28:36 +00:00
|
|
|
summarize_posix_acl(struct posix_acl *acl, struct posix_acl_summary *pas)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-02-16 09:28:36 +00:00
|
|
|
struct posix_acl_entry *pa, *pe;
|
2007-07-17 11:04:36 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only pas.users and pas.groups need initialization; previous
|
|
|
|
* posix_acl_valid() calls ensure that the other fields will be
|
|
|
|
* initialized in the following loop. But, just to placate gcc:
|
|
|
|
*/
|
|
|
|
memset(pas, 0, sizeof(*pas));
|
2007-02-16 09:28:36 +00:00
|
|
|
pas->mask = 07;
|
|
|
|
|
|
|
|
pe = acl->a_entries + acl->a_count;
|
|
|
|
|
|
|
|
FOREACH_ACL_ENTRY(pa, acl, pe) {
|
|
|
|
switch (pa->e_tag) {
|
|
|
|
case ACL_USER_OBJ:
|
|
|
|
pas->owner = pa->e_perm;
|
|
|
|
break;
|
|
|
|
case ACL_GROUP_OBJ:
|
|
|
|
pas->group = pa->e_perm;
|
|
|
|
break;
|
|
|
|
case ACL_USER:
|
|
|
|
pas->users |= pa->e_perm;
|
|
|
|
break;
|
|
|
|
case ACL_GROUP:
|
|
|
|
pas->groups |= pa->e_perm;
|
|
|
|
break;
|
|
|
|
case ACL_OTHER:
|
|
|
|
pas->other = pa->e_perm;
|
|
|
|
break;
|
|
|
|
case ACL_MASK:
|
|
|
|
pas->mask = pa->e_perm;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* We'll only care about effective permissions: */
|
|
|
|
pas->users &= pas->mask;
|
|
|
|
pas->group &= pas->mask;
|
|
|
|
pas->groups &= pas->mask;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* We assume the acl has been verified with posix_acl_valid. */
|
2007-02-16 09:28:30 +00:00
|
|
|
static void
|
2005-04-16 22:20:36 +00:00
|
|
|
_posix_to_nfsv4_one(struct posix_acl *pacl, struct nfs4_acl *acl,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
2007-02-16 09:28:36 +00:00
|
|
|
struct posix_acl_entry *pa, *group_owner_entry;
|
|
|
|
struct nfs4_ace *ace;
|
|
|
|
struct posix_acl_summary pas;
|
|
|
|
unsigned short deny;
|
2005-04-16 22:20:36 +00:00
|
|
|
int eflag = ((flags & NFS4_ACL_TYPE_DEFAULT) ?
|
2007-03-27 05:32:09 +00:00
|
|
|
NFS4_INHERITANCE_FLAGS | NFS4_ACE_INHERIT_ONLY_ACE : 0);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
BUG_ON(pacl->a_count < 3);
|
2007-02-16 09:28:36 +00:00
|
|
|
summarize_posix_acl(pacl, &pas);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
pa = pacl->a_entries;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace = acl->aces + acl->naces;
|
|
|
|
|
|
|
|
/* We could deny everything not granted by the owner: */
|
|
|
|
deny = ~pas.owner;
|
|
|
|
/*
|
|
|
|
* but it is equivalent (and simpler) to deny only what is not
|
|
|
|
* granted by later entries:
|
|
|
|
*/
|
|
|
|
deny &= pas.users | pas.group | pas.groups | pas.other;
|
|
|
|
if (deny) {
|
|
|
|
ace->type = NFS4_ACE_ACCESS_DENIED_ACE_TYPE;
|
|
|
|
ace->flag = eflag;
|
|
|
|
ace->access_mask = deny_mask_from_posix(deny, flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_OWNER;
|
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
|
|
|
}
|
|
|
|
|
|
|
|
ace->type = NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE;
|
|
|
|
ace->flag = eflag;
|
|
|
|
ace->access_mask = mask_from_posix(pa->e_perm, flags | NFS4_ACL_OWNER);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_OWNER;
|
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
2005-04-16 22:20:36 +00:00
|
|
|
pa++;
|
|
|
|
|
|
|
|
while (pa->e_tag == ACL_USER) {
|
2007-02-16 09:28:36 +00:00
|
|
|
deny = ~(pa->e_perm & pas.mask);
|
|
|
|
deny &= pas.groups | pas.group | pas.other;
|
|
|
|
if (deny) {
|
|
|
|
ace->type = NFS4_ACE_ACCESS_DENIED_ACE_TYPE;
|
|
|
|
ace->flag = eflag;
|
|
|
|
ace->access_mask = deny_mask_from_posix(deny, flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_NAMED;
|
2013-02-02 13:18:08 +00:00
|
|
|
ace->who_uid = pa->e_uid;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
|
|
|
}
|
|
|
|
ace->type = NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE;
|
|
|
|
ace->flag = eflag;
|
|
|
|
ace->access_mask = mask_from_posix(pa->e_perm & pas.mask,
|
|
|
|
flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_NAMED;
|
2013-02-02 13:18:08 +00:00
|
|
|
ace->who_uid = pa->e_uid;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
2005-04-16 22:20:36 +00:00
|
|
|
pa++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* In the case of groups, we apply allow ACEs first, then deny ACEs,
|
|
|
|
* since a user can be in more than one group. */
|
|
|
|
|
|
|
|
/* allow ACEs */
|
|
|
|
|
|
|
|
group_owner_entry = pa;
|
2007-02-16 09:28:36 +00:00
|
|
|
|
|
|
|
ace->type = NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE;
|
|
|
|
ace->flag = eflag;
|
|
|
|
ace->access_mask = mask_from_posix(pas.group, flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_GROUP;
|
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
2005-04-16 22:20:36 +00:00
|
|
|
pa++;
|
|
|
|
|
|
|
|
while (pa->e_tag == ACL_GROUP) {
|
2007-02-16 09:28:36 +00:00
|
|
|
ace->type = NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE;
|
|
|
|
ace->flag = eflag | NFS4_ACE_IDENTIFIER_GROUP;
|
|
|
|
ace->access_mask = mask_from_posix(pa->e_perm & pas.mask,
|
|
|
|
flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_NAMED;
|
2013-02-02 13:18:08 +00:00
|
|
|
ace->who_gid = pa->e_gid;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
2005-04-16 22:20:36 +00:00
|
|
|
pa++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* deny ACEs */
|
|
|
|
|
|
|
|
pa = group_owner_entry;
|
2007-02-16 09:28:36 +00:00
|
|
|
|
|
|
|
deny = ~pas.group & pas.other;
|
|
|
|
if (deny) {
|
|
|
|
ace->type = NFS4_ACE_ACCESS_DENIED_ACE_TYPE;
|
2009-08-27 21:35:41 +00:00
|
|
|
ace->flag = eflag;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace->access_mask = deny_mask_from_posix(deny, flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_GROUP;
|
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
pa++;
|
2007-02-16 09:28:36 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
while (pa->e_tag == ACL_GROUP) {
|
2007-02-16 09:28:36 +00:00
|
|
|
deny = ~(pa->e_perm & pas.mask);
|
|
|
|
deny &= pas.other;
|
|
|
|
if (deny) {
|
|
|
|
ace->type = NFS4_ACE_ACCESS_DENIED_ACE_TYPE;
|
|
|
|
ace->flag = eflag | NFS4_ACE_IDENTIFIER_GROUP;
|
2009-08-14 22:02:30 +00:00
|
|
|
ace->access_mask = deny_mask_from_posix(deny, flags);
|
2007-02-16 09:28:36 +00:00
|
|
|
ace->whotype = NFS4_ACL_WHO_NAMED;
|
2013-02-02 13:18:08 +00:00
|
|
|
ace->who_gid = pa->e_gid;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace++;
|
|
|
|
acl->naces++;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
pa++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pa->e_tag == ACL_MASK)
|
|
|
|
pa++;
|
2007-02-16 09:28:36 +00:00
|
|
|
ace->type = NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE;
|
|
|
|
ace->flag = eflag;
|
|
|
|
ace->access_mask = mask_from_posix(pa->e_perm, flags);
|
|
|
|
ace->whotype = NFS4_ACL_WHO_EVERYONE;
|
|
|
|
acl->naces++;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-02-02 13:18:08 +00:00
|
|
|
static bool
|
|
|
|
pace_gt(struct posix_acl_entry *pace1, struct posix_acl_entry *pace2)
|
|
|
|
{
|
|
|
|
if (pace1->e_tag != pace2->e_tag)
|
|
|
|
return pace1->e_tag > pace2->e_tag;
|
|
|
|
if (pace1->e_tag == ACL_USER)
|
|
|
|
return uid_gt(pace1->e_uid, pace2->e_uid);
|
|
|
|
if (pace1->e_tag == ACL_GROUP)
|
|
|
|
return gid_gt(pace1->e_gid, pace2->e_gid);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static void
|
|
|
|
sort_pacl_range(struct posix_acl *pacl, int start, int end) {
|
|
|
|
int sorted = 0, i;
|
|
|
|
struct posix_acl_entry tmp;
|
|
|
|
|
|
|
|
/* We just do a bubble sort; easy to do in place, and we're not
|
|
|
|
* expecting acl's to be long enough to justify anything more. */
|
|
|
|
while (!sorted) {
|
|
|
|
sorted = 1;
|
|
|
|
for (i = start; i < end; i++) {
|
2013-02-02 13:18:08 +00:00
|
|
|
if (pace_gt(&pacl->a_entries[i],
|
|
|
|
&pacl->a_entries[i+1])) {
|
2005-04-16 22:20:36 +00:00
|
|
|
sorted = 0;
|
|
|
|
tmp = pacl->a_entries[i];
|
|
|
|
pacl->a_entries[i] = pacl->a_entries[i+1];
|
|
|
|
pacl->a_entries[i+1] = tmp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
sort_pacl(struct posix_acl *pacl)
|
|
|
|
{
|
|
|
|
/* posix_acl_valid requires that users and groups be in order
|
|
|
|
* by uid/gid. */
|
|
|
|
int i, j;
|
|
|
|
|
2014-04-18 12:49:04 +00:00
|
|
|
/* no users or groups */
|
|
|
|
if (!pacl || pacl->a_count <= 4)
|
|
|
|
return;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
i = 1;
|
|
|
|
while (pacl->a_entries[i].e_tag == ACL_USER)
|
|
|
|
i++;
|
|
|
|
sort_pacl_range(pacl, 1, i-1);
|
|
|
|
|
|
|
|
BUG_ON(pacl->a_entries[i].e_tag != ACL_GROUP_OBJ);
|
2009-10-21 23:45:02 +00:00
|
|
|
j = ++i;
|
2005-04-16 22:20:36 +00:00
|
|
|
while (pacl->a_entries[j].e_tag == ACL_GROUP)
|
|
|
|
j++;
|
|
|
|
sort_pacl_range(pacl, i, j-1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
/*
|
|
|
|
* While processing the NFSv4 ACE, this maintains bitmasks representing
|
|
|
|
* which permission bits have been allowed and which denied to a given
|
|
|
|
* entity: */
|
|
|
|
struct posix_ace_state {
|
|
|
|
u32 allow;
|
|
|
|
u32 deny;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct posix_user_ace_state {
|
2013-02-02 13:18:08 +00:00
|
|
|
union {
|
|
|
|
kuid_t uid;
|
|
|
|
kgid_t gid;
|
|
|
|
};
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
struct posix_ace_state perms;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct posix_ace_state_array {
|
|
|
|
int n;
|
|
|
|
struct posix_user_ace_state aces[];
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* While processing the NFSv4 ACE, this maintains the partial permissions
|
|
|
|
* calculated so far: */
|
|
|
|
|
|
|
|
struct posix_acl_state {
|
2007-02-16 09:28:37 +00:00
|
|
|
int empty;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
struct posix_ace_state owner;
|
|
|
|
struct posix_ace_state group;
|
|
|
|
struct posix_ace_state other;
|
|
|
|
struct posix_ace_state everyone;
|
|
|
|
struct posix_ace_state mask; /* Deny unused in this case */
|
|
|
|
struct posix_ace_state_array *users;
|
|
|
|
struct posix_ace_state_array *groups;
|
|
|
|
};
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static int
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
init_state(struct posix_acl_state *state, int cnt)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
int alloc;
|
|
|
|
|
|
|
|
memset(state, 0, sizeof(struct posix_acl_state));
|
2007-02-16 09:28:37 +00:00
|
|
|
state->empty = 1;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
/*
|
|
|
|
* In the worst case, each individual acl could be for a distinct
|
|
|
|
* named user or group, but we don't no which, so we allocate
|
|
|
|
* enough space for either:
|
|
|
|
*/
|
|
|
|
alloc = sizeof(struct posix_ace_state_array)
|
2008-08-29 23:18:45 +00:00
|
|
|
+ cnt*sizeof(struct posix_user_ace_state);
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
state->users = kzalloc(alloc, GFP_KERNEL);
|
|
|
|
if (!state->users)
|
|
|
|
return -ENOMEM;
|
|
|
|
state->groups = kzalloc(alloc, GFP_KERNEL);
|
|
|
|
if (!state->groups) {
|
|
|
|
kfree(state->users);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static void
|
|
|
|
free_state(struct posix_acl_state *state) {
|
|
|
|
kfree(state->users);
|
|
|
|
kfree(state->groups);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static inline void add_to_mask(struct posix_acl_state *state, struct posix_ace_state *astate)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
state->mask.allow |= astate->allow;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
/*
|
|
|
|
* Certain bits (SYNCHRONIZE, DELETE, WRITE_OWNER, READ/WRITE_NAMED_ATTRS,
|
|
|
|
* READ_ATTRIBUTES, READ_ACL) are currently unenforceable and don't translate
|
|
|
|
* to traditional read/write/execute permissions.
|
|
|
|
*
|
|
|
|
* It's problematic to reject acls that use certain mode bits, because it
|
|
|
|
* places the burden on users to learn the rules about which bits one
|
|
|
|
* particular server sets, without giving the user a lot of help--we return an
|
|
|
|
* error that could mean any number of different things. To make matters
|
|
|
|
* worse, the problematic bits might be introduced by some application that's
|
|
|
|
* automatically mapping from some other acl model.
|
|
|
|
*
|
|
|
|
* So wherever possible we accept anything, possibly erring on the side of
|
|
|
|
* denying more permissions than necessary.
|
|
|
|
*
|
|
|
|
* However we do reject *explicit* DENY's of a few bits representing
|
|
|
|
* permissions we could never deny:
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static inline int check_deny(u32 mask, int isowner)
|
|
|
|
{
|
|
|
|
if (mask & (NFS4_ACE_READ_ATTRIBUTES | NFS4_ACE_READ_ACL))
|
|
|
|
return -EINVAL;
|
|
|
|
if (!isowner)
|
|
|
|
return 0;
|
|
|
|
if (mask & (NFS4_ACE_WRITE_ATTRIBUTES | NFS4_ACE_WRITE_ACL))
|
|
|
|
return -EINVAL;
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static struct posix_acl *
|
|
|
|
posix_state_to_acl(struct posix_acl_state *state, unsigned int flags)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
struct posix_acl_entry *pace;
|
|
|
|
struct posix_acl *pacl;
|
|
|
|
int nace;
|
|
|
|
int i, error = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-02-16 09:28:37 +00:00
|
|
|
/*
|
|
|
|
* ACLs with no ACEs are treated differently in the inheritable
|
2014-04-18 12:49:04 +00:00
|
|
|
* and effective cases: when there are no inheritable ACEs,
|
|
|
|
* calls ->set_acl with a NULL ACL structure.
|
2007-02-16 09:28:37 +00:00
|
|
|
*/
|
2014-04-18 12:49:04 +00:00
|
|
|
if (state->empty && (flags & NFS4_ACL_TYPE_DEFAULT))
|
|
|
|
return NULL;
|
|
|
|
|
2007-02-16 09:28:37 +00:00
|
|
|
/*
|
|
|
|
* When there are no effective ACEs, the following will end
|
|
|
|
* up setting a 3-element effective posix ACL with all
|
|
|
|
* permissions zero.
|
|
|
|
*/
|
2014-04-02 18:59:08 +00:00
|
|
|
if (!state->users->n && !state->groups->n)
|
|
|
|
nace = 3;
|
|
|
|
else /* Note we also include a MASK ACE in this case: */
|
|
|
|
nace = 4 + state->users->n + state->groups->n;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
pacl = posix_acl_alloc(nace, GFP_KERNEL);
|
|
|
|
if (!pacl)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
pace = pacl->a_entries;
|
|
|
|
pace->e_tag = ACL_USER_OBJ;
|
|
|
|
error = check_deny(state->owner.deny, 1);
|
|
|
|
if (error)
|
|
|
|
goto out_err;
|
|
|
|
low_mode_from_nfs4(state->owner.allow, &pace->e_perm, flags);
|
|
|
|
|
|
|
|
for (i=0; i < state->users->n; i++) {
|
|
|
|
pace++;
|
|
|
|
pace->e_tag = ACL_USER;
|
|
|
|
error = check_deny(state->users->aces[i].perms.deny, 0);
|
|
|
|
if (error)
|
|
|
|
goto out_err;
|
|
|
|
low_mode_from_nfs4(state->users->aces[i].perms.allow,
|
|
|
|
&pace->e_perm, flags);
|
2013-02-02 13:18:08 +00:00
|
|
|
pace->e_uid = state->users->aces[i].uid;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
add_to_mask(state, &state->users->aces[i].perms);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
pace++;
|
|
|
|
pace->e_tag = ACL_GROUP_OBJ;
|
|
|
|
error = check_deny(state->group.deny, 0);
|
|
|
|
if (error)
|
|
|
|
goto out_err;
|
|
|
|
low_mode_from_nfs4(state->group.allow, &pace->e_perm, flags);
|
|
|
|
add_to_mask(state, &state->group);
|
|
|
|
|
|
|
|
for (i=0; i < state->groups->n; i++) {
|
|
|
|
pace++;
|
|
|
|
pace->e_tag = ACL_GROUP;
|
|
|
|
error = check_deny(state->groups->aces[i].perms.deny, 0);
|
|
|
|
if (error)
|
|
|
|
goto out_err;
|
|
|
|
low_mode_from_nfs4(state->groups->aces[i].perms.allow,
|
|
|
|
&pace->e_perm, flags);
|
2013-02-02 13:18:08 +00:00
|
|
|
pace->e_gid = state->groups->aces[i].gid;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
add_to_mask(state, &state->groups->aces[i].perms);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-05-15 01:57:26 +00:00
|
|
|
if (state->users->n || state->groups->n) {
|
2014-04-02 18:59:08 +00:00
|
|
|
pace++;
|
|
|
|
pace->e_tag = ACL_MASK;
|
|
|
|
low_mode_from_nfs4(state->mask.allow, &pace->e_perm, flags);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
pace++;
|
|
|
|
pace->e_tag = ACL_OTHER;
|
|
|
|
error = check_deny(state->other.deny, 0);
|
|
|
|
if (error)
|
|
|
|
goto out_err;
|
|
|
|
low_mode_from_nfs4(state->other.allow, &pace->e_perm, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
return pacl;
|
|
|
|
out_err:
|
|
|
|
posix_acl_release(pacl);
|
|
|
|
return ERR_PTR(error);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static inline void allow_bits(struct posix_ace_state *astate, u32 mask)
|
|
|
|
{
|
|
|
|
/* Allow all bits in the mask not already denied: */
|
|
|
|
astate->allow |= mask & ~astate->deny;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static inline void deny_bits(struct posix_ace_state *astate, u32 mask)
|
|
|
|
{
|
|
|
|
/* Deny all bits in the mask not already allowed: */
|
|
|
|
astate->deny |= mask & ~astate->allow;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-02-02 13:18:08 +00:00
|
|
|
static int find_uid(struct posix_acl_state *state, kuid_t uid)
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
{
|
2013-02-02 13:18:08 +00:00
|
|
|
struct posix_ace_state_array *a = state->users;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
int i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
for (i = 0; i < a->n; i++)
|
2013-02-02 13:18:08 +00:00
|
|
|
if (uid_eq(a->aces[i].uid, uid))
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
return i;
|
|
|
|
/* Not found: */
|
|
|
|
a->n++;
|
|
|
|
a->aces[i].uid = uid;
|
|
|
|
a->aces[i].perms.allow = state->everyone.allow;
|
|
|
|
a->aces[i].perms.deny = state->everyone.deny;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
return i;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-02-02 13:18:08 +00:00
|
|
|
static int find_gid(struct posix_acl_state *state, kgid_t gid)
|
|
|
|
{
|
|
|
|
struct posix_ace_state_array *a = state->groups;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < a->n; i++)
|
|
|
|
if (gid_eq(a->aces[i].gid, gid))
|
|
|
|
return i;
|
|
|
|
/* Not found: */
|
|
|
|
a->n++;
|
|
|
|
a->aces[i].gid = gid;
|
|
|
|
a->aces[i].perms.allow = state->everyone.allow;
|
|
|
|
a->aces[i].perms.deny = state->everyone.deny;
|
|
|
|
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static void deny_bits_array(struct posix_ace_state_array *a, u32 mask)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
int i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
for (i=0; i < a->n; i++)
|
|
|
|
deny_bits(&a->aces[i].perms, mask);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static void allow_bits_array(struct posix_ace_state_array *a, u32 mask)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
int i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
for (i=0; i < a->n; i++)
|
|
|
|
allow_bits(&a->aces[i].perms, mask);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
static void process_one_v4_ace(struct posix_acl_state *state,
|
|
|
|
struct nfs4_ace *ace)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
u32 mask = ace->access_mask;
|
|
|
|
int i;
|
|
|
|
|
2007-02-16 09:28:37 +00:00
|
|
|
state->empty = 0;
|
|
|
|
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
switch (ace2type(ace)) {
|
|
|
|
case ACL_USER_OBJ:
|
|
|
|
if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
|
|
|
|
allow_bits(&state->owner, mask);
|
|
|
|
} else {
|
|
|
|
deny_bits(&state->owner, mask);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ACL_USER:
|
2013-02-02 13:18:08 +00:00
|
|
|
i = find_uid(state, ace->who_uid);
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
|
|
|
|
allow_bits(&state->users->aces[i].perms, mask);
|
|
|
|
} else {
|
|
|
|
deny_bits(&state->users->aces[i].perms, mask);
|
|
|
|
mask = state->users->aces[i].perms.deny;
|
|
|
|
deny_bits(&state->owner, mask);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ACL_GROUP_OBJ:
|
|
|
|
if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
|
|
|
|
allow_bits(&state->group, mask);
|
|
|
|
} else {
|
|
|
|
deny_bits(&state->group, mask);
|
|
|
|
mask = state->group.deny;
|
|
|
|
deny_bits(&state->owner, mask);
|
|
|
|
deny_bits(&state->everyone, mask);
|
|
|
|
deny_bits_array(state->users, mask);
|
|
|
|
deny_bits_array(state->groups, mask);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ACL_GROUP:
|
2013-02-02 13:18:08 +00:00
|
|
|
i = find_gid(state, ace->who_gid);
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
|
|
|
|
allow_bits(&state->groups->aces[i].perms, mask);
|
|
|
|
} else {
|
|
|
|
deny_bits(&state->groups->aces[i].perms, mask);
|
|
|
|
mask = state->groups->aces[i].perms.deny;
|
|
|
|
deny_bits(&state->owner, mask);
|
|
|
|
deny_bits(&state->group, mask);
|
|
|
|
deny_bits(&state->everyone, mask);
|
|
|
|
deny_bits_array(state->users, mask);
|
|
|
|
deny_bits_array(state->groups, mask);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ACL_OTHER:
|
|
|
|
if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
|
|
|
|
allow_bits(&state->owner, mask);
|
|
|
|
allow_bits(&state->group, mask);
|
|
|
|
allow_bits(&state->other, mask);
|
|
|
|
allow_bits(&state->everyone, mask);
|
|
|
|
allow_bits_array(state->users, mask);
|
|
|
|
allow_bits_array(state->groups, mask);
|
|
|
|
} else {
|
|
|
|
deny_bits(&state->owner, mask);
|
|
|
|
deny_bits(&state->group, mask);
|
|
|
|
deny_bits(&state->other, mask);
|
|
|
|
deny_bits(&state->everyone, mask);
|
|
|
|
deny_bits_array(state->users, mask);
|
|
|
|
deny_bits_array(state->groups, mask);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
static int nfs4_acl_nfsv4_to_posix(struct nfs4_acl *acl,
|
|
|
|
struct posix_acl **pacl, struct posix_acl **dpacl,
|
|
|
|
unsigned int flags)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-02-16 09:28:29 +00:00
|
|
|
struct posix_acl_state effective_acl_state, default_acl_state;
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
struct nfs4_ace *ace;
|
|
|
|
int ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-02-16 09:28:29 +00:00
|
|
|
ret = init_state(&effective_acl_state, acl->naces);
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
if (ret)
|
2007-02-16 09:28:29 +00:00
|
|
|
return ret;
|
|
|
|
ret = init_state(&default_acl_state, acl->naces);
|
|
|
|
if (ret)
|
|
|
|
goto out_estate;
|
|
|
|
ret = -EINVAL;
|
2007-02-16 09:28:30 +00:00
|
|
|
for (ace = acl->aces; ace < acl->aces + acl->naces; ace++) {
|
[PATCH] knfsd: nfsd4: acls: relax the nfsv4->posix mapping
Use a different nfsv4->(draft posix) acl mapping which is
1. completely backwards compatible,
2. accepts any nfsv4 acl, and
3. errs on the side of restricting permissions.
In detail:
1. completely backwards compatible: The new mapping produces the
same result on any acl produced by the existing (draft
posix)->nfsv4 mapping; the one exception is that we no longer
attempt to guess the value of the mask by assuming certain denies
represent the mask. Since the server still keeps track of the mask
locally, sequences of chmod's will still be handled fine; the only
thing this will change is sequences of chmod's with intervening
read-modify-writes of the acl. That last case just isn't worth the
trouble and the possible misrepresentations of the user's intent
(if we guess that a certain deny indicates masking is in effect
when it really isn't).
2. accepts any nfsv4 acl: That's not quite true: we still reject
acls that use combinations of inheritance flags that we don't
support. We also reject acls that attempt to explicitly deny
read_acl or read_attributes permissions, or that attempt to deny
write_acl or write_attributes permissions to the owner of the file.
3. errs on the side of restricting permissions: one exception to
this last rule: we totally ignore some bits (write_owner,
synchronize, read_named_attributes, etc.) that are completely alien
to our filesystem semantics, in some cases even if that would mean
ignoring an explicit deny that we have no intention of enforcing.
Excepting that, the posix acl produced should be the most
permissive acl that is not more permissive than the given nfsv4
acl.
And the new code's shorter, too. Neato.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 09:16:11 +00:00
|
|
|
if (ace->type != NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE &&
|
|
|
|
ace->type != NFS4_ACE_ACCESS_DENIED_ACE_TYPE)
|
2007-02-16 09:28:29 +00:00
|
|
|
goto out_dstate;
|
2006-10-04 09:16:12 +00:00
|
|
|
if (ace->flag & ~NFS4_SUPPORTED_FLAGS)
|
2007-02-16 09:28:29 +00:00
|
|
|
goto out_dstate;
|
2007-02-16 09:28:28 +00:00
|
|
|
if ((ace->flag & NFS4_INHERITANCE_FLAGS) == 0) {
|
2007-02-16 09:28:29 +00:00
|
|
|
process_one_v4_ace(&effective_acl_state, ace);
|
2006-10-04 09:16:12 +00:00
|
|
|
continue;
|
2007-02-16 09:28:28 +00:00
|
|
|
}
|
2007-02-16 09:28:29 +00:00
|
|
|
if (!(flags & NFS4_ACL_DIR))
|
|
|
|
goto out_dstate;
|
2007-02-16 09:28:28 +00:00
|
|
|
/*
|
|
|
|
* Note that when only one of FILE_INHERIT or DIRECTORY_INHERIT
|
|
|
|
* is set, we're effectively turning on the other. That's OK,
|
|
|
|
* according to rfc 3530.
|
|
|
|
*/
|
2007-02-16 09:28:29 +00:00
|
|
|
process_one_v4_ace(&default_acl_state, ace);
|
|
|
|
|
|
|
|
if (!(ace->flag & NFS4_ACE_INHERIT_ONLY_ACE))
|
|
|
|
process_one_v4_ace(&effective_acl_state, ace);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2007-02-16 09:28:29 +00:00
|
|
|
*pacl = posix_state_to_acl(&effective_acl_state, flags);
|
|
|
|
if (IS_ERR(*pacl)) {
|
|
|
|
ret = PTR_ERR(*pacl);
|
2007-07-17 11:04:37 +00:00
|
|
|
*pacl = NULL;
|
2007-02-16 09:28:29 +00:00
|
|
|
goto out_dstate;
|
|
|
|
}
|
2007-02-16 09:28:37 +00:00
|
|
|
*dpacl = posix_state_to_acl(&default_acl_state,
|
|
|
|
flags | NFS4_ACL_TYPE_DEFAULT);
|
2007-02-16 09:28:29 +00:00
|
|
|
if (IS_ERR(*dpacl)) {
|
|
|
|
ret = PTR_ERR(*dpacl);
|
2007-07-17 11:04:37 +00:00
|
|
|
*dpacl = NULL;
|
2007-02-16 09:28:29 +00:00
|
|
|
posix_acl_release(*pacl);
|
2007-07-17 11:04:37 +00:00
|
|
|
*pacl = NULL;
|
2007-02-16 09:28:29 +00:00
|
|
|
goto out_dstate;
|
|
|
|
}
|
|
|
|
sort_pacl(*pacl);
|
|
|
|
sort_pacl(*dpacl);
|
|
|
|
ret = 0;
|
|
|
|
out_dstate:
|
|
|
|
free_state(&default_acl_state);
|
|
|
|
out_estate:
|
|
|
|
free_state(&effective_acl_state);
|
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-12-20 13:16:55 +00:00
|
|
|
__be32
|
|
|
|
nfsd4_set_nfs4_acl(struct svc_rqst *rqstp, struct svc_fh *fhp,
|
|
|
|
struct nfs4_acl *acl)
|
|
|
|
{
|
|
|
|
__be32 error;
|
|
|
|
int host_error;
|
|
|
|
struct dentry *dentry;
|
|
|
|
struct inode *inode;
|
|
|
|
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 = dentry->d_inode;
|
|
|
|
|
|
|
|
if (!inode->i_op->set_acl || !IS_POSIXACL(inode))
|
|
|
|
return nfserr_attrnotsupp;
|
|
|
|
|
|
|
|
if (S_ISDIR(inode->i_mode))
|
|
|
|
flags = NFS4_ACL_DIR;
|
|
|
|
|
|
|
|
host_error = nfs4_acl_nfsv4_to_posix(acl, &pacl, &dpacl, flags);
|
|
|
|
if (host_error == -EINVAL)
|
|
|
|
return nfserr_attrnotsupp;
|
|
|
|
if (host_error < 0)
|
|
|
|
goto out_nfserr;
|
|
|
|
|
|
|
|
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)) {
|
|
|
|
host_error = inode->i_op->set_acl(inode, dpacl,
|
|
|
|
ACL_TYPE_DEFAULT);
|
|
|
|
}
|
|
|
|
|
|
|
|
out_release:
|
|
|
|
posix_acl_release(pacl);
|
|
|
|
posix_acl_release(dpacl);
|
|
|
|
out_nfserr:
|
|
|
|
if (host_error == -EOPNOTSUPP)
|
|
|
|
return nfserr_attrnotsupp;
|
|
|
|
else
|
|
|
|
return nfserrno(host_error);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static short
|
|
|
|
ace2type(struct nfs4_ace *ace)
|
|
|
|
{
|
|
|
|
switch (ace->whotype) {
|
|
|
|
case NFS4_ACL_WHO_NAMED:
|
|
|
|
return (ace->flag & NFS4_ACE_IDENTIFIER_GROUP ?
|
|
|
|
ACL_GROUP : ACL_USER);
|
|
|
|
case NFS4_ACL_WHO_OWNER:
|
|
|
|
return ACL_USER_OBJ;
|
|
|
|
case NFS4_ACL_WHO_GROUP:
|
|
|
|
return ACL_GROUP_OBJ;
|
|
|
|
case NFS4_ACL_WHO_EVERYONE:
|
|
|
|
return ACL_OTHER;
|
|
|
|
}
|
|
|
|
BUG();
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct nfs4_acl *
|
2007-02-16 09:28:30 +00:00
|
|
|
nfs4_acl_new(int n)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct nfs4_acl *acl;
|
|
|
|
|
2007-02-16 09:28:30 +00:00
|
|
|
acl = kmalloc(sizeof(*acl) + n*sizeof(struct nfs4_ace), GFP_KERNEL);
|
|
|
|
if (acl == NULL)
|
2005-04-16 22:20:36 +00:00
|
|
|
return NULL;
|
|
|
|
acl->naces = 0;
|
|
|
|
return acl;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct {
|
|
|
|
char *string;
|
|
|
|
int stringlen;
|
|
|
|
int type;
|
|
|
|
} s2t_map[] = {
|
|
|
|
{
|
|
|
|
.string = "OWNER@",
|
|
|
|
.stringlen = sizeof("OWNER@") - 1,
|
|
|
|
.type = NFS4_ACL_WHO_OWNER,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.string = "GROUP@",
|
|
|
|
.stringlen = sizeof("GROUP@") - 1,
|
|
|
|
.type = NFS4_ACL_WHO_GROUP,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.string = "EVERYONE@",
|
|
|
|
.stringlen = sizeof("EVERYONE@") - 1,
|
|
|
|
.type = NFS4_ACL_WHO_EVERYONE,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
int
|
|
|
|
nfs4_acl_get_whotype(char *p, u32 len)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2006-03-24 11:15:34 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(s2t_map); i++) {
|
2005-04-16 22:20:36 +00:00
|
|
|
if (s2t_map[i].stringlen == len &&
|
|
|
|
0 == memcmp(s2t_map[i].string, p, len))
|
|
|
|
return s2t_map[i].type;
|
|
|
|
}
|
|
|
|
return NFS4_ACL_WHO_NAMED;
|
|
|
|
}
|
|
|
|
|
2013-08-28 01:32:25 +00:00
|
|
|
__be32 nfs4_acl_write_who(struct xdr_stream *xdr, int who)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2013-08-28 01:32:25 +00:00
|
|
|
__be32 *p;
|
2005-04-16 22:20:36 +00:00
|
|
|
int i;
|
|
|
|
|
2006-03-24 11:15:34 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(s2t_map); i++) {
|
2014-01-08 14:49:01 +00:00
|
|
|
if (s2t_map[i].type != who)
|
|
|
|
continue;
|
2013-08-28 01:32:25 +00:00
|
|
|
p = xdr_reserve_space(xdr, s2t_map[i].stringlen + 4);
|
|
|
|
if (!p)
|
2014-01-08 14:49:01 +00:00
|
|
|
return nfserr_resource;
|
2013-08-28 01:32:25 +00:00
|
|
|
p = xdr_encode_opaque(p, s2t_map[i].string,
|
2014-01-08 14:49:01 +00:00
|
|
|
s2t_map[i].stringlen);
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2014-01-08 14:49:01 +00:00
|
|
|
WARN_ON_ONCE(1);
|
2005-04-16 22:20:36 +00:00
|
|
|
return -1;
|
|
|
|
}
|