Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1442402 > unrolled thread
| Started by | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| First post | 2016-07-13 14:40 +0200 |
| Last post | 2016-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.
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
| From | Andreas Gruenbacher <agruenba@redhat.com> |
|---|---|
| Date | 2016-07-13 14:40 +0200 |
| Subject | Re: [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]
| From | "Frank Filz" <ffilzlnx@mindspring.com> |
|---|---|
| Date | 2016-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