Use section for permission conflict resolution [5.2.1]

In-Portal permission system uses "everything is disallowed except what was allowed explicitly" model. The permissions are checked in 2 places:

• in the template - to ensure, that user permissions to view data displayed on that template
• before event is executed (e.g. form submit) - to ensure, that user have permissions to perform an action, that is done by an event

Typical permission name looks like this: in-portal:users_list.edit, where:

• in-portal:users_list - section name
• edit - type of access, that is requested within that section

The permission name is specified in templates as-is because they non-parsed templates never leave the server. User only gets back from server template parts that he/she have permissions to access.

For events, that permission name is determined from event itself. Typical event, submitted from browser, looks like this: u:OnUpdate, where:

• u - unit config prefix in the "users" unit, which has "in-portal:users_list" section defined in it
  
• OnUpdate - the event name in the "users" unit, which is mapped to "edit" permission

This way same "in-portal:users_list.edit" permission name is reconstructed safely on the server without way for intruder to get access to protected data.

Problem

Described above solution works flawlessly, when section unit has only 1 section. However when unit has 2 or more sections (e.g. the "users" unit has both "in-portal:user_list" and "in-portal:admins" sections defined), then there is no way to determine which section name to use for event permission checking. To temporarily solve the problem the "main unit permission section" concept was introduced. It allows to always use a specific section, when there are more than 1 defined in a particular unit.

The side effect of this is that other sections, defined in the unit are never used for permission checking even when they should.

Solution

1. add the section parameter to m unit query string definition (http://qa.in-portal.org/diffusion/INP/browse/branches%252F5.2.x/in-portal/branches/5.2.x/core/units/general/general_config.php;16154$22-29) - 0.2h
2. always pass "m_section" url parameter (will be included into env url parameter), when building urls in the Admin Console tree (see http://qa.in-portal.org/diffusion/INP/browse/branches%252F5.2.x/in-portal/branches/5.2.x/core/units/helpers/sections_helper.php;16154$245) - 0.3h
3. don't use perm_prefix key to replace non-primary unit section with primary one (e.g. in-portal:admins with in-portal:user_list) when saving/showing group permissions (see http://qa.in-portal.org/D52 for code places, but the changed code needs to be removed at all to use $section_name as-as) - 0.5h
4. write an upgrade script, that will copy permission grants for all non-primary unit sections from unit's primary section (only mentioned section uses perm_prefix in core code, so it's a simple SQL query) - 0.3h
5. when declaring section use SectionPrefix key for specifying associated unit instead of perm_prefix key (no coding required for that) - 0.2h
6. in places, where the perm_prefix setting from section definition is used we need to use SectionPrefix (always present) instead: - 0.5h
   1. the kEvent::getSection method
   2. the kSectionsHelper::getPermSection method
7. improve the kSectionsHelper::getPermSection method by: - 0.5h
   1. adding optional $prefix parameter
   2. when $prefix parameter is given we:
      1. look for "m_section" request variable
      2. if found and is declared in the unit, which prefix is given, then use it as permission section
   3. invoke current code (use section's unit main unit permission section name) when:
      1. $prefix parameter is not given
      2. the m_section request variable is empty
      3. section given in m_section request variable is defined in another unit
      4. section given in m_section request variable not defined at all
8. in places, where kSectionsHelper::getPermSection method is called we need to provide the $prefix parameter:- 1h
   1. the "adm::SectionInfo" tag (from the combined_header block)
   2. the "adm::PrintSections" tag (from Admin Tree)
   3. the "adm::ListTabs" tag (grids with tabs, e.g. discounts)
   4. in the "\kSectionsHelper::sectionVisible" method (called from "adm::DrawTree" tag, "adm::PrintSections" tag, "kSectionsHelper::getFirstChild" method)
   5. the "adm::DrawTree" tag (from group permission editing screen) - indirect call
   6. the "kSectionsHelper::getFirstChild" method (from "adm::PrintSection" tag) - indirect call

Quote: 3.5h*1.4 (doing) + 1.5h (quoting) = 6.5h

Related Tasks

INP-1782 - Getting issue details... STATUS