subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Support character classes in glob authz rules
Date Mon, 03 Dec 2018 15:28:24 GMT
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@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.


Mime
View raw message