unintended read access to all project areas
I created a user id called DEF_DEV1 which is not a member of any project area on my RTC 4.0.4 installation. A test project area contains a stream and a component owned by this project area. The visibility is limited to the project area. Surprisingly the DEF_DEV1 user id has access to all files in the test project area.
Any Idea how I can limit the read access to a project area to the members of this project area?.
Kind Regards, Steffen
5 answers
I just installed RTC 4.0.4 and tried to reproduce the steps that you did, I could not observe the same behavior.
As an assumption, when I was testing the part where you said "has access to all files in the test project area.", I was testing to see if that user could see the Stream in the team artifacts view of in the Eclipse RTC clinet (an likewise use "Show" --> "Repository Files" on a component). Note: This is a stream which has the owner and visibility is the project area as you mentioned).
Some explanations for that behavior however include:
-In the Project Area editor, on the "Access Control" tab, if the selection is on "Everyone" instead of "Members of the project area hierarchy" then any user could see the source.
-Otherwise, if the "Access Control" is set to "Members of the project area hierarchy", then the user could see the source. (perhaps he was added as a member by accident somehow)
-The user could also have a repository permission role of "JazzAdmins", and it would not matter if he was assigned a stakeholder, contributor, or developer license, they would still be able to see the source.
-Another explanation, however unlikely, is that you changed the license or repository permission in the web-ui, and either forgot to hit save, or the request didn't go through.
I also verified what Ralph said in the same 4.0.4 Install you tried.
ex:
1. The project has access control. If It is readable by everyone, everyone can access everything on project level, unless otherwise hidden.
2. If someone has no license at all, they can not access the source code (but the work items)
3. If a stream is owned by a project area the visibility is always project area level - you can't change it. So who can access the project area and has a license can access it.
4. If a stream is owned by a team, AND the visibility is limited to the team, only team members can open the team
5. If you limit access control, only users that have access can access the project data.
As a reference for anyone reading this, here's information on what the the different licenses allow a user to do (reminder, the contributor license has read access to source, but not write access, and the stakeholder license does not even have read access to source - I verified this in my RTC 4.0.4 Install):
https://jazz.net/library/article/548/
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/index.jsp?topic=%2Fcom.ibm.jazz.repository.web.admin.doc%2Ftopics%2Fc_license_mgmt_over.html
Here are some articles and blogs about how permissions work in RTC (and some different ways to hide source from users)
-Process permissions lookup in Rational Team Concert 2.0 (https://jazz.net/library/article/291)
-Process behavior lookup in Rational Team Concert 2.0 (https://jazz.net/library/article/292)
-Enhanced source control permissions in the next release of Rational Team Concert (RTC 3.0.1) (https://jazz.net/blog/index.php/2011/05/23/enhanced-source-control-permissions-in-the-next-release-of-rational-team-concert/)
-Patterns for read-protecting source code (RTC 2.0) https://jazz.net/blog/index.php/2009/05/21/patterns-for-read-protecting-source-code-2/
-Getting Started with Project Areas and Process in Rational Team Concert 2.0 (RTC 2.0) (https://jazz.net/library/article/137/)
- The access control specified for the project area that owns the component that contains that file
- The access control specified for a particular file.
You can see the content of a file version only if you have read access to the component, and you have read access to the particular file.
Note that I have said nothing about streams. That is because read access to a stream only determines whether you are allowed to see what is the current configuration of that stream. Even with no read access to any stream, if you have read access to a component, you can see all of the change sets in that component, which gives you access to the content of all versions of all files in that component (except for a file that has explicit access control that doesn't let you see any of the versions of that file).
In order to control read access, the access control on a stream is largely irrelevant
I think the user might be assigned Jazzadmin repository permission. it will be having an access to all the files but not able to modify any changes ( unless he has got assigned roles in the project area and developer licenses)
Uncheck the JazzAdmin Repository Permission and give JazzUser repository permission.
I don't think so you can limit the read-access on the source files under component but you can restrict by enforcing permission to modify the files.
Please let me know if you need any further information.
Regards,
Arun
If you want to limit read access to a project, check the access tab. That tab allows you to restrict read access to the members of the project.
You can also try to set the visibility of the streams to a team area inside of the project. I think that should hide it from users not in the team area.
I know in the past, to make it sure the code can not be seen, but work items can, the suggestion was to use one open project for work items and another project with access limitations for SCM. This makes it unlikely for users not supposed to see any code, even if someone accidentally changed the visibility. As far as I know this is how we develop RTC and the other products too. The work items are in one project, the code is in one with limited access rights.
I am not sure if the user being able to see the code is by design, even if visibility is limited to the project area. You might want to file a PMR or defect for that, if you think this is a defect. I will check soon, if I see the same.
Comments
Steffen, I just tried it and it is consistent, like it or not, with my description above.
1. The project has access control. If It is readable by everyone, everyone can access everything on project level, unless otherwise hidden.
2. If someone has no license at all, they can not access the source code (but the work items)
3. If a stream is owned by a project area the visibility is always project area level - you can't change it. So who can access the project area and has a license can access it.
4. If a stream is owned by a team, AND the visibility is limited to the team, only team members can open the team
5. If you limit access control, only users that have access can access the project data.
If you take away the developer license, and just leave contributor or stakeholder, then those users will not have any access to the source.. (no access)
that is how we setup our system to satisfy the auditors, and was the IBM recommended solution.
and I just confirmed that stakeholder and contributor do not have access to the source control elements.(components or streams)
only workitems
Sam, I tried that with 4.0.5 RC1 and the user still can see the code with
- a stakeholder or contributor license
- only having guest repository role
Hm.. here I logged on with my user Mark, who is contributor, with the project connected in Eclipse under a user who DID have access
I see the component names in the web ui, but not the files, change sets..
this is 4.0.3 server
Please try the Web UI, Sam.
ok, eclispe UI with developer user
web view for contributor user
I did not hide on component level, because the question was for the stream level.
I did not change any settings.. this is OOtB behavior. If I change the user license to developer everything shows up.
Here is a contributor user not in the project browsing a stream - I tried different browsers too. Note 4.0.5 RC1
Hm.. when I try to access the flow targets with the contrib user I get
sounds like there is a security regression in 4.0.5 rc1
I am not sure what the status on 4.0.5 is. I will try to pass that on.
and just to add the rest of the data. the user Mark on my system has JazzUser and JazzProjectAdmin repo access set, AND is a member of the project (Stakeholder)
(If I add 'team member' no change)
If I then change the user client access license type from contributor to developer, the user has access to the source on both web and eclipse.
This was a version that was not yet released, however, I have noticed someone to have a look.
I tested the behavior in 4.0.4 and 4.0.5 and am observing the same expected behavior (see my answer to the main question).
Note: Even with the correct membership/access, users with stakeholder licenses should not be able to see source code. Users with contributor licenses should have 'read' access to the source, but not write access. And the developer role license allows read and write of source. From there, process area membership, access, stream / component ownership/visibility can be applied to control the access of source further.
(see the URLS posted in my original answer to the question on the expected behavior with regards to the licenses)
It's possible that I missed where the possible regression or issues were as per the discussion above, if you think I did, please mention what behavior you think is broken specifically, and on which version of RTC and I can try to re-verify.
Note that in general, you should never be using license assignment as a form of read-access control. It may be that certain data is (or appears to be) hidden if you don't have a particular license, but you should not count on that behavior being true in all GUI's, and should not count on that behavior as staying true from release to release.
Ralf,
we have one project area for work items and several other project areas for source code. We need to limit the read access to each source code project area to the members of this project area. Only people with need to know must have read permissions to the source code. From the RTC documentation and your comments this should work by limiting the visibility of components to project or team areas. I was prototyping this for our RTC 4.0.4 test installation and found that all users on the server have read access even if they are not a member on any project area.
The behavior is independent form the RTC client I see the same in windows, linux, eclipse or web client.
Regards, Steffen
My answer as well as the answer of my peers Geoff and David, as I interpret them, is to set the Access Control of the projects hosting source to something other than "Everyone".
Every other attempt is too error prone, labor intensive and doomed to fail in the long term.
Unfortunately, that alone is not enough. there are valid reasons for user without source read access to have access to a project.
In my prior case it was the Support personnel, who needed to work on workitems, but were not allowed to see the source.
If you want different read access for a component from work items, just create a new project area with the right access control for the component, and change the ownership of that component to be that new project area.
Comments
Steffen Kriese
Nov 28 '13, 4:25 p.m.Some screen shots from my scenario:
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
The user ID is not member of any project:
The user ID has no repository permissions:
The user ID has a developer licenses:
The user management is done via LDAP:
DEF_DEV1 is not a member of the project area:
The access is limited to members of the project hierarchy:
the visibility of the component is limited to he project area:
the ID DEF_DEV1 can see the java code:
Steffen Kriese
Nov 28 '13, 4:26 p.m.Did some more investigations:
the file read access permission for all files is set to public. When creating a new file the read access permission is also set to public. Is there a way to change the read access permission?
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 28 '13, 4:40 p.m.When you say "has access to all files in the test project area", what specifically did that user do to read those files?