Ido M. Tamir wrote:
> On Tuesday 14 July 2009 15:25:47 you wrote:
>> Hello Ido,
>> We're sorry to hear that you have encountered problems in working with
>> dataset libraries and security in Galaxy. Please see my explanations
>> below, and let me know if more clarification is needed or if you come
>> across behavior that differs from that described.
> Unfortunately I am a bit slow and need more clarification. The behavior
> does not differ from what you described and there I think lies my problem.
>> 1) manage permissions: Role members can manage the roles associated with
>> this dataset
>> 2) access: Role members can import this dataset into their history for
>> analysis. NOTE: Users must have every role associated with the access
>> permission on this dataset in order to access it
> It is this NOTE that I don't understand. In every other case you allow one
> of each role. In this case you require that it fits all of the roles.
All roles are required because of the complication of derived
permissions for datasets that are produced from running jobs on
different input datasets. Take, for example, two datasets, DatasetA,
and DatasetB. Access to DatasetA requires a user to be associated with
RoleA, and access to DatasetB with RoleB. It follows that DatasetAB (
created by running a tool with DatasetA and DatasetB as inputs ) should
have both RoleA and RoleB associated for the access permission.
However, if ANY associated role was sufficient, this would allow users
who are only associated either RoleA OR RoleB to view data which was
originally not accessible to them.
>> The "library dataset" permission "access" is a restrict permission. If
>> no roles are associated with it, the library dataset is considered
>> public, and all users can access it in the library. However, if a role
>> is associated with the "access" permission on the library dataset, a
>> user must have that role in order to access the dataset in the library.
>> If more than 1 role is associated with the "access" permission, then
>> a user must have all roles in order to access it.
> But why do you model this permission like this - requiring all roles?
See above explanation
>>> You require that the user should have all of the roles that are currently
>>> associated with the library. This makes simple things difficult and
>>> complicated things impossible.
>> This is not necessarily the case - for example, user can have
>> permission to add a library item, but not manage library permissions.
>> What behavior are you seeing that leads you to this conclusion?
> I actually only talk about the "access" permission. Here the user has
> to have all the roles associated with him (should have pointed this
> out more).
>> Do you mean user/group ( Galaxy has no concept that would differentiate
>> a user from a bioinformatician )? It depends on how you set up your
>> groups of users. You could have 1 group with all users, and associate
>> that group with a role, then associate that role with each "library"
> But then as soon as I add a new user, that should not have access to the
> datasets all the other users have, this policy scheme breaks down.
> Maybe I can explain what I intend in an example - and then you can
> tell me how I should actually do this:
> users (I simplify and say no user is in more than one group):
> userName group
> user1 group1
> user2 group2
> user3 bioinfo
> user4* group4
> user4 is a collaborator of user1 - he should have access to the data
> of user1 - not to the rest of group1 data.
> Dataset owner
> A user1
> B user2
> I would normally solve my policy problem by creating the following roles:
> role members
> r_u1 user1*
> r_u2 user2*
> r_u3 user3*
> r_u4 user4*
> r_g1 group1**
> r_g2 group2**
> r_g4 group4**
> r_b user3
> *I think galaxy automatically creates roles from users or allows association
> of libraries with users, so this might not be necessary.
Galaxy automatically creates a "private" role for each user, but this is
the only role that is automatically created.
> **I think galaxy automatically adds the roles of the groups one is member of
> to the users roles, so I don't add user1 to r_u1 etc...
> Then I would associate the following privileges with the datasets
> Dataset modify access
> A r_u1,r_b r_u1,r_g1,r_b,r_u4
> B r_u2,r_b r_u2,r_g2,r_b
> Galaxy does not allow me to grant these access privileges, because
> there is no user having all the roles.
> It would be very simple to solve, if you would model the access permission
> like you model all the other permissions.
Hopefully my comments above clarify why this is necessary. The roles
associated with the access permission on a dataset are "and", not "or".
Otherwise data security quickly breaks down on datasets derived from
others. I agree that it's tricky, but ensuring data is only accessible
by the desired users was our highest priority in implementing RBAC.
> Thank you very much for you time,