+++ This bug was initially created as a clone of Bug #747725 +++

There's a bug in our regular expression that we use for oid validation.

If you have a OID url like:
content/dist/rhel/rhui/server/6/$releasever/$basearch/os

That gets changed to the following regular expression string:
content/dist/rhel/rhui/server/6/.+?/.+?/os

This happens in oid_validation.py in _validate_url.

This resulting regular expression matches too much.  The intent is that any requested url that starts with content/dist/rhel/rhui/server/6/<release>/<arch>/os is allowed.  However, it will actually allow other urls like:
/pulp/repos//content/dist/rhel/rhui/server/6/6Server/x86_64/mrg-g/2.0/os

The arch regular expression ends up matching x86_64/mrg-g/2.0.  In fact, it will match any thing up to the os.

Example:
/home/jslagle $ python
Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) 
[GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> oid = 'content/dist/rhel/rhui/server/6/.+?/.+?/os'
>>> url = '/pulp/repos//content/dist/rhel/rhui/server/6/6Server/x86_64/mrg-g/2.0/os'
>>> re.search(oid, url)
<_sre.SRE_Match object at 0x7fb67fa54370>

And:
>>> url = '/pulp/repos//content/dist/rhel/rhui/server/6/6Server/x86_64/my/super/secret/repo/os'
>>> re.search(oid, url)
<_sre.SRE_Match object at 0x7fb67fa543d8>

--- Additional comment from jslagle on 2011-10-20 17:36:38 EDT ---

Instead of using '.+?' to match the release and arch, it looks like instead we should be using '[^/]+'.  Using the latter, we'll basically match any character other than '/', which is what we want when matching the release and arch.

The problem with using '.+?' is that even though we've specified the '?', making the regex non-greedy, it will still match against as much of the string as needed to satisfy the regex.  Non-greedy doesn't mean only match up to the next character ('/' in this case), it means take the minimal amount of the string possible in order to satisfy the match.  The second usage of '.+?' will happily match as possible, such as 'x86_64/mrg-g/2.0' so that it can find a match and satisfy the regex.

--- Additional comment from jslagle on 2011-10-24 15:03:05 EDT ---

Committed to pulp master and RHUI branch.

pulp master:
commit 06b17d5cf4d02be3f2bc75a36c30d9e6880c6c4d
Author: James Slagle <jslagle>
Date:   Mon Oct 24 14:56:43 2011 -0400

    747725 Fix regular expression during oid validation and add a test that uses

rhui: 948709966ff7bc3ec9a02f0d82dabeb7fbe97038


I also found another problem in that we were using re.search instead of re.match.  re.search will search the whole string instead of verifying that the requested uri *starts* with the oid url.  If you had a oid url like rhel/server/6, and a repo at /my/super/secret/repo/rhel/server/6, requests to that repo would have been allowed given that oid url.

Switching to re.match will ensure that the requested URI must start with the oid url.

--- Additional comment from jslagle on 2011-10-25 08:37:04 EDT ---

Verification:

Make sure you have the MRG repos added and sync'd to your RHUI that match at least one of your base versions of RHEL.  For example, if you RHEL 6Server i386 sync'd, at MRG for 6Server i386.

Generate an entitlement certificate for the base RHEL 6 repo.  What we want to verify is that that certificate does *not* give you access to MRG.  You can generate a client config rpm for the MRG repos and point it at the entitlement certificate for the RHEL 6 repo.  Then verify that you are denied access to the MRG repos.  Another way to do it would be to just generate a client config rpm for the MRG repos as normal, but then edit the yum repo config file and point it at an entitlement certificate for the base RHEL 6 repo.

As this touches our repo auth code, it's probably a good idea to do some other general verification around this area, just verifying in general that the generated entitlement certificates do give you access to only what you asked for.