Feature changed by: Adrian Schröter (adrianSuSE)
Feature #306517, revision 17
Title: Read access control to obs projects
Requested by: Scott Bahling (sbahling)
Partner organization: openSUSE.org
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
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.
Business case (Partner benefit):
: 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
#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
#3: Adrian Schröter (adriansuse) (2010-04-21 17:22:15)
EngManager and Developer is actual "Martin Mohring", but fate does not
#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
#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.