Gotcha; thanks.
I think there are two basic (non-regex) patterns that are likely to be
useful:
1) Cross-profile perms
/profile=*/subsystem=logging
vs
/profile=default/subsystem=logging
/profile=ha/subsystem=logging
...
/profile=prof-52/subsystem=logging
2) Granting perms for an address and its children/
/subsystem=logging/**
Clean handling of 2) is a must. I'm sure we'd get complaints if we
didn't support 1).
But full regex support isn't needed for those two.
On 4/25/16 10:07 AM, Anil Saldanha wrote:
Hi Brian - I was just making a generic statement about staying away
from
pattern matching in ACLs given it is hard to debug and the possibility
of Allow instead of Deny in unintended cases. Having explicit grants
will make it cleaner.
On Mon, Apr 25, 2016 at 9:28 AM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
On 4/25/16 8:09 AM, Anil Saldanha wrote:
The challenge with pattern based matching is that you provide
access when you should not. Explicit definition of the grants is
recommended.
So I support your thinking, Brian.
Did you mean you support Ladislav's thinking? His proposed approach
is more explicit.
On Apr 25, 2016, at 7:55 AM, Brian Stansberry
<brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
Perhaps. I'm a bit bit reluctant to move away from something
powerful
and standard to something custom. Mostly because it's hard
to move the
other way in the future while remaining compatible. But your
point is
well taken.
How would you propose discriminating these cases?
1) /subsystem=messaging is not allowed but its children are.
2) /subsystem=messaging and its children are.
We also need to think about ObjectName patterns, which are not
inherently hierarchical.
On 4/23/16 1:38 AM, Ladislav Thon wrote:
I only have a single comment: writing a regular
expression can sometimes
be a bit tricky. Just see the example you used:
(/profile=[^/]+)??/subsystem=logging(/.*)*
It's also fairly easy to write a regular expression that
doesn't quite
do what you want it to do, in some corner cases.
Finally, some
well-crafted regular expressions have running time in
years or more (at
least in the java.util.regex implementation).
This all leads me to believe that maybe regular
expressions are not the
best choice.
Instead, I'm thinking about address prefixes. So the
role would be
specified by a set of valid addresses (including the "*"
wildcard), and
only the specified resources and all their children
would be accessible.
I'm specifically not thinking about _textual_ prefix, so
e.g. prefix of
/subsystem=messaging would give you access to the old
messaging
subsystem, but it _wouldn't_ give you access to the new
/subsystem=messaging-activemq, even if
/subsystem=messaging is a textual
prefix.
Granted, that's way less powerful than regular
expressions, but also
easier and safer to use.
WDYT? Am I being too paranoid here?
LT
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat