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 * usern...@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.
