Notary list requires admin permission in 0.6.0

[molepigeon]

We have some images in our registry (and corresponding information in notary) that is read-only to most users. Since updating to notary 0.6.0, that read-only content hasn't been accessible. We get:

$ notary -D list registry.eu-de.bluemix.net/ibmliberty
DEBU[0000] Configuration file not found, using defaults 
DEBU[0000] Using the following trust directory: /home/molepigeon/.notary 
DEBU[0000] No yubikey found, using alternative key storage: no library found 
DEBU[0000] Making dir path: /home/molepigeon/.notary/tuf/registry.eu-de.bluemix.net/ibmliberty/changelist 
Enter username: token
Enter password: 
DEBU[0005] received HTTP status 401 when requesting root. 

* fatal: you are not authorized to perform this operation: server returned 401.

Output of notary version:

notary
 Version:    0.6.0
 Git commit: d25e8c4e

We're using token auth for both Registry and Notary.

We've traced the problem to that Notary goes to the Oauth server asking for a * permission when performing a list. Because the user only has read-only access to the GUN, they're (correctly) given a 401, which is presented to the user.

For 0.4.3 clients, our auth server logs:
Requested scopes: [{{repository registry.eu-de.bluemix.net/ibmliberty } pull}]

But in 0.6.0:
Requested scopes: [{{repository registry.eu-de.bluemix.net/ibmliberty } *}]

As shown above, this is a regression from 0.4.3.

The server returns a well-formed auth challenge with the correct scope if you make a request without auth:

$ curl -v https://registry.eu-de.bluemix.net:4443/v2/registry.eu-de.bluemix.net/ibmliberty/_trust/tuf/root.json 2>&1 | grep "<"
< HTTP/1.1 401 Unauthorized
< Server: nginx
< Date: Fri, 02 Mar 2018 16:43:57 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 180
< Connection: keep-alive
< Www-Authenticate: Bearer realm="https://registry.eu-de.bluemix.net/oauth/token",service="notary",scope="repository:registry.eu-de.bluemix.net/ibmliberty:pull"
< 

I spent some time investigating the issue, and making sure that the problem is client side. I found that tufCommander.tufList used to call getTransport with readOnly as the permission in 0.4.3. Now, it calls ConfigureRepo, which in turn calls getTransport with admin.

The way I see it, there's at least two options for how we can address this; the quick fix would be to make notary list use the readOnly permission again, and the harder one would be to make the notary client attempt the request to the specific resource without auth and craft an auth request according to the auth challenge the server sends.

I'm happy to work on a fix for this, but would like to know which option to take before starting coding.

What are your thoughts?

[cyli]

Thanks for finding this @molepigeon and apologies for the regression! It seems like maybe updating ConfigureRepo to take readOnly or admin permissions would be simplest.