Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1442402 > unrolled thread

Re: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

Started byAndreas Gruenbacher <agruenba@redhat.com>
First post2016-07-13 14:40 +0200
Last post2016-07-13 21:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl Andreas Gruenbacher <agruenba@redhat.com> - 2016-07-13 14:40 +0200
    RE: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl "Frank Filz" <ffilzlnx@mindspring.com> - 2016-07-13 21:50 +0200

#1442402 — Re: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

FromAndreas Gruenbacher <agruenba@redhat.com>
Date2016-07-13 14:40 +0200
SubjectRe: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl
Message-ID<rUrCi-34n-17@gated-at.bofh.it>
Frank,

On Tue, Jul 5, 2016 at 7:08 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
>> > + * Note: functions like richacl_allowed_to_who(),
>> > +richacl_group_class_allowed(),
>> > + * and richacl_compute_max_masks() iterate through the entire acl in
>> > +reverse
>> > + * order as an optimization.
>> > + *
>> > + * In the standard algorithm, aces are considered in forward order.
>> > +When a
>> > + * process matches an ace, the permissions in the ace are either
>> > +allowed or
>> > + * denied depending on the ace type.  Once a permission has been
>> > +allowed or
>> > + * denied, it is no longer considered in further aces.
>> > + *
>> > + * By iterating through the acl in reverse order, we can compute the
>> > +same
>> > + * result without having to keep track of which permissions have been
>> > +allowed
>> > + * and denied already.
>> > + */
>> >
>>
>> Clever!
>
> Hmm, but does that result in examining the whole ACL for most access checks, at least for files where most of the accesses are by the owner, or a member of a specific group (with perhaps a ton of special case users added on the end)?

I don't understand -- what does this algorithm have to do with access checks?

Thanks,
Andreas

[toc] | [next] | [standalone]


#1442791

From"Frank Filz" <ffilzlnx@mindspring.com>
Date2016-07-13 21:50 +0200
Message-ID<rUykq-7ut-23@gated-at.bofh.it>
In reply to#1442402
> > Hmm, but does that result in examining the whole ACL for most access
> checks, at least for files where most of the accesses are by the owner, or a
> member of a specific group (with perhaps a ton of special case users added
> on the end)?
> 
> I don't understand -- what does this algorithm have to do with access checks?

Oh, sorry, misread the patch... got caught up looking at a tree and not seeing the forest...

Frank



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web