On 03.12.2018 11:42, Julian Foad wrote:
> Branko Čibej wrote:
>>> 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.
> Accepted.
>
>> 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. :)
> Ones that Subversion otherwise accepts, apart from in this context.
>
>> We've always had the following restictions: usernames can't begin with
>> '@' or '&' or '~',
> There must be also limitations with '#', '*', '=' and whitespace characters, and I don't see a way to find a complete list.
True. Also '$' since we have the magic '$authenticated' and '$anonymous'
tokens.
The rules are not explicitly documented anywhere, but they're implied by
the documentation in The Book. With a bit of luck, I'll have these
spelled out on the wiki some day.
>> 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.
> We haven't heard vocal complaints. It could well have caused headaches for those implementing authz in their systems. (Not because they need to use such usernames, but because they need to defensively program against an incompletely known set of problems.)
Well, realistically, user identifiers are likely to take one of the
following forms, with reasonable variations:
* usernme
* name.surname
* username_at_example.com
* CN=Name Surname,OU=marketing,DC=example,DC=com
While some authentication systems (pam_unix FTW) theoretically allow
funny usernames with leading '@', '&', '$' etc., such names are very,
very unlikely to be used in practice. Our authz parser will accept any
of the forms I listed above.
(The Distinguished Name has to be mapped through an alias because it
containe '=', this is documented in The Book.)
> Would I be totally off the mark in suggesting an enhancement request for an authz file format that addresses these issues? It seems to me this is the sort of thing "enterprise" users would value.
I don't think it's necessary. And until and unless we get an actual bug
report, I'd leave well enough alone. Inventing some escaping mechanism
post-hoc always leads to strange side effects, making some currently
valid identifiers suddenly invalid or interpreted differently.
-- Brane
P.S.: Users can't have ':' in the name of a repository for
repository-specific rules, either; this, too have never been a problem.
Received on 2018-12-03 16:28:32 CET