Unexpected behavior in the ProGet Permissions system

The permissions system in ProGet is contra-intuitive and potentially dangerous.

Lets assume a case with 3 users A, B, C and 2 repositories R1, R2. All users are in the Active Directory/LDAP backend.

User A does not have any custom permissions set.
User B does have (Admin/devel) permissions to R1, no permission set to R2.
User C does have deny admin permissions to R1 and admin permissions to R2.

Case: User A browses to the local ProGet site.

Expected outcome: A can view the site, but does not see any feeds and does not have a way to determine the name of feeds of the system.

What actually happens in ProGet: A can view the site, sees some links containing feed names, but many lead to 500 error pages.

Case: User B browses to the local ProGet site.

Expected outcome: B can view and upload packages for R1, but cannot find out there is a repo R2.

What actually happens in ProGet: B can view the site, maybe sees a broken link with another feed name in it, but cannot actually upload any packages, because of Error 500. This is because no entry with Deny for R2 has been created.

Case: The administrator adds a new feed R3 to the ProGet repository and grants A developer permissions to R3.

Expected outcome: A can now download and publish packages to R3.

What actually happens in ProGet: The system breaks for the unrelated users B, C; they are confronted with 500 errors.

A possible solution might be to give (system) permissions to everyone, then add Deny entries.

This is not recommended because this means that:

on every change in the feed layout, all users permissions have to be updated. As soon as there are more than a handful of users, the effort to do this quickly becomes prohibitive.
Deny entries are managed separately from Grant. This means it's easy to forget one or the other. ProGet breaks down for the user for some of these cases, but not for all (remove Grant, do not remove Deny -> breaks. Remove Deny, do not remove Grant -> does not break).

But the most important problem is that a change to one part of the system (adding a feed visible for A alone) breaks the system in other parts (users B and C on repos R1 and R2).

The cause of this weird and unintuitive behavior seems to be the handling of the "No permissions" case.

The expected behavior would be to require an entry to to get access to something, and denying access otherwise.

ProGet insists that we

Create an Entry granting Access to the item that should be invisible.
Create an Entry that denies the access to the item.

If we do not follow this approach, ProGet fails to function properly and throws error 500 pages.

This is less a support request than a request to fix the behavior. An important reason why people buy ProGet is that it offers authentication to NuGet feeds, that is, to limit access to them. I feel that the way the permissions system was designed hinders this purpose, because it makes administration more complex and error prone.

The 500 error pages you're experiencing are security errors (the error message will indicate "not authorized for task"); we may change the status code in a future release to 403.

We cannot reproduce "The system breaks for the unrelated users B, C; they are confronted with 500 errors". If you send a back-up of your database to our support address, we can look at your data.

ProGet's security model is documented here. The "restricting view access to authenticated users" use case is not very common, and thus the privileges system is not designed around feed-by-feed security.

Hi Alex,

Thank you for rephrasing my entry . It might be better for transparency if you added a "Message edited by Inedo Staff" or similar disclaimer; now it seems I wrote things which I did not.

But back to the topic at hand:

The breaking can be easily reproduced as follows:

Assume a working ProGet with a few users and repos. Create a new repo and do not add a permissions entry for a specific user.

The specific user now cannot use the upload functionality for the repos he was granted access before anymore, as the missing permissions to the new repo will make any click on the upload packages screen throw a 500 error.

Do you mean the "Upload Package" link on the home page?

This is the same thing identified in Question #910, and that has been captured in PG-121. There is a link displayed to a page that the user does not have privileges to access.

Currently, the "Add Package" page allows for upload to all feeds, which is why a scoped privilege does not allow you to use the page. If you have restricted feeds, you can add packages via nuget.exe or any other tool that uses the API.

Most users will use BuildMaster (or another build/release tool) to upload packages to ProGet with the API.

I am fixing this and will push a new version with the fix applied shortly.

Hi Jonas,

Did the newest version resolve your issue?

Hi John,

I just tested the fix, and it indeed solves the problem. I am impressed how quickly this was handled!

Thanks a lot!