Tuesday, January 4, 2011

Gallery Server Pro 2.4.5 Released

Version 2.4.5 of Gallery Server Pro was released today. The WPI version should be available within a week or so soon after the release of 2.4.6. A number of bugs were fixed, including a couple of important security issues. Also, a few minor features were added to enhance usability.

To upgrade, follow the instructions in the Admin Guide.

Security fixes

Two security issues were identified and fixed:

1. Gallery admin can elevate his or her own access and that of other users.

This issue is serious because it allows a user to elevate his or her permission to that of site administrator. The vulnerability exists in two locations:

  • On the Manage Users page, a gallery administrator is able to create a new user with site administration privileges.
  • The User Settings page allows an administrator to specify a role that all new users are automatically added to, including a role that provides site administration access.

The gallery admin cannot directly elevate her access, but she can create a site administrator, then log in as that user, which *does* have permission to elevate the gallery admin to a site admin.

Although this vulnerability is serious, it affects few users. It is not exploitable by anonymous users or any logged on user unless they are in a role with ‘Allow administer gallery’ permission. Gallery admins are users that an administrator has already given a certain amount of trust, so they are not your average malicious user. Also, the concept of a gallery administrator is new in 2.4, so it is likely there are few accounts that are vulnerable.

2. User can delete album on 'delete objects' page without 'delete child album' permission as long as user has 'delete media object' permission.

I would be surprised if anyone is actually affected by this issue because it requires that a user be given permission to delete media objects in an album but not permission to delete albums. In this scenario, the user is still able to delete albums.

Both security issues are fixed in 2.4.5.

Complete list of bug fixes

  • (Described above) Gallery admin can elevate his or her own access and that of other users.
  • (Described above) User can delete album on 'delete objects' page without 'delete child album' permission as long as user has 'delete media object' permission
  • User with 'delete album' permission but not 'delete media object' permission cannot access Delete objects page
  • Cannot override 'Allow downloading ZIP archive' options on the Gallery Control Settings page
  • Disabling 'Show Header' option on Gallery Settings page causes website title URL to be set to blank string
  • Error when navigating media objects: "The server method 'GetMediaObjectHtml' failed"
  • Album Owner Template role not hidden by default on Manage Users and Manage Roles pages
  • (DotNetNuke only) NullReferenceException during call to PerformMaintenance() function
  • (DotNetNuke only) NullReferenceException during call to AddMembershipDataToGallerySettings() function
  • (DotNetNuke only) Album owner function does not work when a long username and/or long role name is involved
  • Role not saved correctly when name exceeds maximum allowed length
  • Thumbnail images appear below treeview
  • (Stand-alone version only) Error "Connection string cannot be blank" during 2.3 to 2.4 upgrade
  • User album not deleted when admin disables user album on Manage Users page

New features

  • (Details below) Ability to restrict gallery admins from managing users and roles
  • (Details below) Allow a gallery admin to give an existing user access to gallery
  • (Details below) Album Owner Template role is unique to each gallery
  • Include users who are gallery admins in the 'toggle admin' filter on Gallery Settings and User Settings pages

Ability to restrict gallery admins from managing users and roles
Allow a gallery admin to give an existing user access to gallery

Recall that each installation of Gallery Server Pro can contain multiple galleries, and each gallery can be assigned an administrator. Before 2.4.5, the following rules were enforced:

  1. A gallery admin could create users and roles. (The DotNetNuke module had an additional requirement that the user must also be in the Administrators role.)
  2. A gallery admin could see users and roles that have access to the gallery he or she administers, but other users and roles are hidden.

Both of these rules are appropriate in many cases, but additional flexibility was required. A site administrator might not want to allow a gallery admin to be able to create users or roles. And the second rule created an issue where a gallery admin could not give an existing user access to his or her gallery.

To solve these issues, two application-level settings were added:

New_app_settings_2.4.5

By default both options are enabled. There isn’t a change in behavior for the first option, since previous versions also let gallery admins manage users and roles. But now gallery admins are able to view users and roles that do not have access to a gallery they manage. I felt that it would be fairly common for a gallery admin to want to give an existing user access to a gallery he or she manages, so that is why it is now enabled by default.

Album Owner Template role is unique to each gallery

Recall that users’ access to albums is managed by their role membership. Two features use roles behind the scenes – album ownership and user albums. If you are not sure what these are, the Admin Guide has a full discussion. The short story is that these features automatically create roles and apply them to users.

When a role is created, it is copied from a template role called the album owner template role. This role is automatically created when needed and by default is given all permissions except for admin gallery and admin site. You, as the administrator, can edit the permissions on this template role to control which permissions a user gets when they are assigned as the owner of an album or are given a new user album.

Prior to 2.4.5, this template role was named “_Album Owner Template”. There was only a single template role, regardless of how many galleries you had. This violated the concept of gallery isolation, since a single role could be edited by multiple gallery admins. For example, gallery admin Bob could edit the template role for gallery A, but so could gallery admin Vino in gallery B.

Starting in 2.4.5, each gallery gets its own template role, and it is given a name that is unique to each gallery, such as “_Album Owner Template (Gallery ID 2: 'Engineering')”

What does this mean for upgraders? Well, nothing if you never use the album ownership or user albums feature. It also doesn’t affect you if you never edited the role “_Album Owner Template”. However, if you changed the permission on this role, you will need to re-apply the same permissions to the new album owner template role. It will be created the first time it is needed – an easy way to trigger its creation is to temporarily make a user an owner of an album (do this in each gallery).

A final note: Since GSP no longer uses the original template role “_Album Owner Template”, you can safely delete it.