Frank,

On Tue, Jul 5, 2016 at 7:08 PM, Frank Filz [off-list ref] wrote:

quoted

quoted

+ * 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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs