This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 841381 - Erroneous caching of project read-only status prevents editing
Erroneous caching of project read-only status prevents editing
Status: CLOSED CURRENTRELEASE
Product: Zanata
Classification: Community
Component: Security (Show other bugs)
1.6.1
Unspecified Unspecified
high Severity high
: ---
: 1.7
Assigned To: Alex Eng
Ding-Yi Chen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-18 15:57 EDT by Alex Eng
Modified: 2012-09-12 23:17 EDT (History)
2 users (show)

See Also:
Fixed In Version: 1.7-SNAPSHOT (20120720-0026)
Doc Type: Bug Fix
Doc Text:
Cause: Improper handling of access permission into editor workspace. First person's permission applies to all other users. Consequence: Wrong permission will be apply to users in workspace according to the first person's permission. Fix: Editor workspace handles individual's access permission.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-11 01:11:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alex Eng 2012-07-18 15:57:10 EDT
Description of problem:
Currently, workspace is only checking individual's permission upon creation. Any access to the workspace after that will have the same permission as the first individual regardless of their role.


If a workspace is being created first time in server with user with full access, subsequent users will have full access in the workspace regardless the status of the project/version and their role.

Likewise, if the workspace gets created by a translators(not maintainer or admin) and the project/version status is being readOnly, then subsequent users will have readonly access regardless of their role. 

Version-Release number of selected component (if applicable):
1.6.1

How reproducible:
Always

Steps to Reproduce:
1. Make sure the server is restarted without any workspace being created.
2. Login as translator, and enter a workspace.
3. Logout and login again as admin, change the status of the version into readonly, and try to go into the same workspace, you will have readonly access.
Comment 2 Sean Flanigan 2012-07-18 20:29:54 EDT
Backporting to 1.6.
Comment 3 Sean Flanigan 2012-07-18 22:08:50 EDT
Backported as https://github.com/zanata/zanata/commit/e8c1fe21048b6ade3fe64a38e90c2cbed9746029 (untested), but on second thoughts, 1.7 is so close it's not worth doing the 1.6.2 point release.
Comment 4 Alex Eng 2012-07-19 02:14:01 EDT
Correction on the steps to reproduce:
1. Make sure the server is restarted without any workspace being created.
2. Login as admin, and enter a workspace - A.
3. Logout and login again as normal translator which have only read access to workspace A. Click on the "Open" link, translator will have write access which is wrong.


This problem triggered by security check on individual only happens on the first instance - when workspace first being created.

Another method to reproduce:
1. Make sure the server is restarted without any workspace being created.
2. Login as translator, and enter a workspace which you have only read access.
3. Logout and login again as admin, go to  workspace A. Admin will have only read only access which is wrong.
Comment 5 Ding-Yi Chen 2012-07-19 20:54:21 EDT
Revised steps to reproduce:

1. Make sure the server is restarted without any workspace being created.
2. Login as translator, and enter a document which you have only read access, such as the language you are not yet a member.
3. Logout and login again as admin, go to  workspace A. Admin will have only read only access which is wrong.


VERIFIED with Zanata version 1.7-SNAPSHOT (20120720-0026)

Note You need to log in before you can comment on or make changes to this bug.