lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 15 May 2015 16:51:40 -0400
From:	bfields@...ldses.org (J. Bruce Fields)
To:	Andreas Gruenbacher <andreas.gruenbacher@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org
Subject: Re: [RFC v3 19/45] richacl: Also recognize nontrivial
 mode-equivalent acls

On Fri, Apr 24, 2015 at 01:04:16PM +0200, Andreas Gruenbacher wrote:
> So far, richacl_equiv_mode() is relatively limited in the types of acl it
> considers equivalent to a file mode: it only accepts masked acls with a single
> everyone@:rwpxd::allow entry.
> 
> Change this to consider all acls equivalent to file modes if they only consist
> of owner@, group@, and everyone@ entries and the owner@ permissions do not
> depend on whether the owner is a member in the owning group.
> 
> Signed-off-by: Andreas Gruenbacher <agruenba@...hat.com>
> ---
>  fs/richacl_base.c       | 150 ++++++++++++++++++++++++++++++++++++++----------
>  include/linux/richacl.h |   1 +
>  2 files changed, 122 insertions(+), 29 deletions(-)
> 
> diff --git a/fs/richacl_base.c b/fs/richacl_base.c
> index db27542..54cb482 100644
> --- a/fs/richacl_base.c
> +++ b/fs/richacl_base.c
> @@ -439,49 +439,141 @@ richacl_inherit(const struct richacl *dir_acl, int isdir)
>  }
>  
>  /**
> - * richacl_equiv_mode  -  check if @acl is equivalent to file permission bits
> - * @mode_p:	the file mode (including the file type)
> + * __richacl_equiv_mode  -  compute the mode equivalent of @acl
>   *
> - * If @acl can be fully represented by file permission bits, this function
> - * returns 0, and the file permission bits in @mode_p are set to the equivalent
> - * of @acl.

This comment is a little confusing:

> + * This function does not consider the masks in @acl.

Given that we do this later:

> +	if (acl->a_flags & RICHACL_MASKED) {
> +		owner.allowed &= acl->a_owner_mask;
> +		group.allowed &= acl->a_group_mask;
> +		everyone.allowed &= acl->a_other_mask;
> +	}

I think the difference is that here you're checking that the end result
after applying masks is mode-equivalent, whereas in riachacl_equiv_mode:

> +	if (acl->a_flags & RICHACL_MASKED) {
> +		mode_t mask = richacl_masks_to_mode(acl);
> +		unsigned int x;
> +
> +		/* Mask flags we can ignore */
> +		x = ~(RICHACE_POSIX_ALWAYS_ALLOWED |
> +		      (S_ISDIR(mode) ? 0 : RICHACE_DELETE_CHILD));
> +
> +		if (((acl->a_group_mask ^ richacl_mode_to_mask(mask >> 3)) & x) ||
> +		    ((acl->a_other_mask ^ richacl_mode_to_mask(mask)) & x))
> +			return -1;
> +
> +		x &= ~RICHACE_POSIX_OWNER_ALLOWED;
> +		if ((acl->a_owner_mask ^ richacl_mode_to_mask(mask >> 6)) & x)
> +			return -1;
> +
> +		mode &= ~S_IRWXUGO | mask;
> +	}

... you're also checking whether the masks themselves are
mode-equivalent?  Is that the right thing to do?

I've probably misread the code again....

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ