On 03.12.2018 10:39, Julian Foad wrote:
> Branko Čibej wrote:
>> I can't think of a solution that would not depart from ConfigParser
>> semantics in one way or another. As for "the system" ... well, the fact
>> that config and authz parsing shares common code is really just an
>> accident, and certainly an implementation detail.
> OK, that's fair. Your solution does seem to be a backward-compatible way that practically should work well to cope with this case.
>
> I was going to say "this new case", but the square-bracket problem is not new with glob rules: any filename can have square brackets in it, on Unix.
Yes, the original issue #4204 predates glob rules.
> If we treat the authz format as its own format, that does make me wonder if there are any other limitations the current ConfigParser format is applying, that should also be lifted.
>
> For example, if "@harry" is parsed as a reference to group name "harry", then is there also a way to specify a username that is literally "@harry"?
Well, first of all, this has nothing to do with the ConfigParser, but
with how our authz infrastructure interprets the access entry selectors.
And no, there's no way to do this.
> In general, is there a programmatic transformation from arbitrary valid user names and paths to corresponding authz entries?
Define "arbitrary valid" and I'll answer that. :)
We've always had the following restictions: usernames can't begin with
'@' or '&' or '~', and similar limitations apply to group and alias
names. Such identifiers have always been rejected at one stage or
another, and this has not been a problem.
Paths in rules are interpreted literally (either as literal paths or as
literal glob patterns), without any excaping mechanism. This hasn't
changed since the inception of authz rules, either. The only really
problematic case is having ']' in the rule, and with glob patterns, this
becomes more likely (or desired).
-- Brane
Received on 2018-12-03 10:58:27 CET