Feature changed by: Adrian Schröter (adrianSuSE) Feature #306517, revision 17 Title: Read access control to obs projects Buildservice: Done Milestone: 2.3 Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Scott Bahling (sbahling) Partner organization: openSUSE.org Description: A project owner defines which other projects are granted read access to this project. Let's call the projects with read access the 'reader list' of the project. Only other projects on the reader list are allowed to use sources or build results from this project; repositories share the permissions of their respective projects. Individual users act on behalf of projects. Thus they gain read access either by being member of the project or by being mamber of a project on the reader list. This is needed to manually build packages locally. When a project or a user has no read access, the project will not be visible. Any links seem to be broken, pointing to an inexistent object. Any read access control failures must pretend this, because project names already can reveal upcoming product properties. For the same reason, the reader list must only be accessible to project members. If read access is withdrawn from a project, already built results must no longer be accessible to the now unauthorized projects and their members. So semantically, a cached expanded source link or a built binary 'knows' which other projects have been used for its creation; read access is only granted to the intersection of the reader lists of all these projects at the time of the access. Obviously this can be cached, too, until the read access is updated. The read access is discretionary. This means, if a user has gotten hold of a source or a binary while she had access to it, she has the data on her disk and the obs will not provide means to take it back if read access should be withdrawn. For that reason, a 'which users and projects dos this reader list expand to' function must be provided, to make things obvious and to allow for what-if probes before changing the reader list. For reliable testing of build results, it's desirable to have the result of publishing available even for read access restricted projects. This would simplify and harden testing, giving testers a most end user like experience. For the record, it has been discussed to introduce 'real ACLs', allowing to withdraw access from some individuals or projects before granting access to a superset. It also has been proposed to optionally 'include' the acl from another project. And it has been proposed to add user groups in addition to projects. These three proposals at frist glance seem to simplify administration, but they also increase complexity of the read access and make it quickly obscure and non- obvious. This proposal here tries to keep it short and simple. References: http://wiki.opensuse.org/openSUSE:Build_Service_Concept_ACL#Adding_code_for_... Business case (Partner benefit): openSUSE.org: Component vendors and system vendors consider it a significant competitive advantage to hide technical details about upcoming products until the product is publicly released. Thus privacy control is crucial for a self serviced operation of a driver build. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:56:40) Diserable for our 2.0 release. Mandatory for ISV build. #2: Adrian Schröter (adriansuse) (2010-04-19 09:44:40) (reply to #1) k, LF want to do an extra release just for this feature (1.8). This feature is currently implemented by Martin Moring and Jan-Simon Möller from LinuxFoundation. #3: Adrian Schröter (adriansuse) (2010-04-21 17:22:15) EngManager and Developer is actual "Martin Mohring", but fate does not know him. #4: Adrian Schröter (adriansuse) (2010-09-17 14:47:32) OBS 2.1 will just have the control to protect sources, but not entire projects or binaries. OBS 2.2 is planned to focus on complete read permission handling only. #5: Martin Mohring (martinmohring) (2010-09-20 17:27:12) I am known to openFATE as login martinmohring #6: Martin Mohring (martinmohring) (2010-09-20 17:29:29) Am update on the implementation is available on http://en.opensuse.org/openSUSE:Build_Service_Concept_ACL #7: Adrian Schröter (adriansuse) (2011-04-04 13:32:20) Implementation looks to be complete, except for some last fixme's. + #8: Adrian Schröter (adriansuse) (2012-04-17 09:27:59) + the last fixme's are also solved. + The only issue, which would need improving is that existing projects + can not become hidden. -- openSUSE Feature: https://features.opensuse.org/306517