[
http://jira.jboss.com/jira/browse/JBPORTAL-2033?page=comments#action_1242... ]
Sohil Shah commented on JBPORTAL-2033:
--------------------------------------
The core problem with this issue lies with the visual/usability of the CMSAdmin tool.
This filtering is required only by the UI and what to display to make things more
intuitive in the Admin tool. Hence, this filtering occurs only within the context of the
CMS Admin tool GUI.
All other accesses like programmatic access via the Command API, will result in proper
resources based on read access etc specified in the security policy.
On the CMS Admin tool UI side, a Folder will no longer be hidden as long as it has atleast
"read" access on that folder. (This will be in the new fix)
However, the files displayed inside a Folder will be filtered out based on user having
atleast "write acess" to it. If only "read" access is available to the
"file", this file will be filtered from the Folder View in the CMS Admin tool.
The argument for filtering the file being:
say you have a folder with a 100 files, each with different security policies on those
files. Now, when a user tries to use the tool, there is no reason to clutter the
user's view with files that he/she has no privilege to do anything with inside the
Admin tool. It tries to show only the files in the Folder, that the user can actually do
something to when inside the Admin tool.
User with only read-permissions on a folder cannot read a folder
----------------------------------------------------------------
Key: JBPORTAL-2033
URL:
http://jira.jboss.com/jira/browse/JBPORTAL-2033
Project: JBoss Portal
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Portal CMS
Affects Versions: 2.6.5 SP1
Reporter: Wulf Rowek
Assigned To: Sohil Shah
Fix For: 2.6.6 Final
In the ACLInterceptor is special part of code (applyFilter method), which was obousily
created to hide items from a user which have no write access and browse in a tool portlet
(i.e. CMSAdmin)
but this aim should not be satisfied on ACL-Level, in my opinion, cause it's a
contradiction, that a user have read permission but cannot read the item.
and to read a folder by a user seems to be a legitimate request, even if he has no write
permission, i.e. to build a folder-index and browse a folder.
possible solution: specify the need of the result in the command (i.e. only read or
something else) and don't filter, if the result of the command will be needed for
reading only.
or maybe better: filter on application level, after the result was catched from the
command by the excecuter
at this moment, i just commented out this line in applyFiler
securityContext.removeAttribute("command");
to disable this feature at all and to give read-permitted users read access
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira