Menu
▾
▴
#40 correction to privilege hierarchy
Sets read as a child privilege of cms_read_item.
This means that a permission check on the read
privilege WILL return cms items (which are always
granted cms_read_item)
Tested on Oracle - trigger correctly updates all
existing records in the dnm.... tables. Untested on
Postgres.
Guessed on the version numbers - assumed upgrade from
6.3.0 to 6.3.1
Chris.....
Logged In: YES
user_id=67512
Integrated to trunk at r1014.
Logged In: YES
user_id=1069385
****** UNEXPECTED SIDE EFFECT *******
If you go to the site without an application context, the
jsp page ccm-cms/web/packages/content-section/www/content-
center-redirect.jsp checks if the current user has access
to any content sections and if so, redirects to the
content centre, else redirects to the workspace specified
in config (eg the homepage)
Strangely, ....viewer content reader group in each content
section has cms_read_item access granted on each content
section. Before patch the jsp page access check works
because it checks for read access not cms_read_item, and
historically, content authors have been explicitly granted
read access to the content sections as well as
cms_read_item but viewers have not.
This patch means that suddenly non logged in users have
permission to view content sections and so they are
directed to the content-centre.
The easiest fix is to remove the cms_read_item permission
granted on EACH content section to the associated viewer
group. I have tracked through request logging and can find
nowhere where this permission is checked - checks are
generally on a specific content item etc.
If this is the best approach, I expect a code change will
be needed somewhere because presumably when new content
sections are created, this cms_read_item privilege is
granted to viewer groups.
Chris......
Logged In: YES
user_id=1069385
Additional upgrade statement required to remove read
privileges granted to content Administration and hence
inherited by content Viewers. Something like:
delete from acs_permissions a
where a.grantee_id in (select group_id from groups
where lower(name) = 'content administration' or lower
(name) = 'forms administration')
and a.privilege = 'read'
I suspect the inclusion of these was a previous
workaround - content administration was granted read
access on the root folder, so all subfolders inherited
this. This would have helped with some of the hierarchy
issues. However, as content viewer is a sub group of
content administration this means that content viewers
have read access to any content items hence if you remove
read access from viewers on a folder, they fail check on
cms_read_item but pass check on read
This statement additionally removes read privilege on
content section granted to content administration. This
privilege means content viewers could access the content
section backend if they had the url, or if they
just put in the site address without /ccm then they would
be directed straight to the content centre. As in my
previous comment, there is a need to stop this privilege
being granted when a new content section is created.
Chris.....
Logged In: YES
user_id=1069385
IMPORTANT -
Please see both follow up comments - if this patch goes
into release 1.0.4, this issue will affect anyone that has
additional content sections (eg from creating subsites)
and anyone that creates new content sections.
For the former, upgrade scripts are required to remove
read privilege granted to '{section name} administration'
group on all sections and remove cms_read_item privilege
granted to '{section name} administration Content Reader'
group on all sections.
For the latter, we need to prevent these privileges being
granted when a new content section is created.
I don't know where these privileges are set - is it in
ContentSectionSetup. We manually deleted permissions from
our DB, and have suffered no adverse effects (we went live
with this in Nov 2005)
Chris.....