Hi, a) I have problems with your conception of roles in your RBAC scheme. Normally in RBAC[1] a subject can execute a transaction if the currently active roles of the user allow this. 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. My policy should be: each user can do everything with his own dataset. the group of a user can access (view and push it to history) the library. a group of bioinformaticians can do everything with allmost all libraries. How would you implement this in your sheme which requires "all of the roles"? Would I have to create a new role for each combination of user/group/bioinformaticians? If you would require just "one of the roles", you would simply add 1) the user as a role to the lib (for everything) 2) the group the user is in as a role to the lib (for pushing to history + view if this is implemented) 3) the bioinformatician group as a role to the lib (for everything) b) An important permission would be to be able to view the item. I played around (maybe not enough) but could not find a way to really hide an item (library, folder, dataset) from the view. c) The little arrow pointing down to bring up the context-menu is very small. It would be helpful if you could maybe make it bigger or turn it into a button. thank you very much, Ido [1] http://csrc.nist.gov/groups/SNS/rbac/documents/Role_Based_Access_Control-199...
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. Ido M. Tamir wrote:
Hi,
a) I have problems with your conception of roles in your RBAC scheme. Normally in RBAC[1] a subject can execute a transaction if the currently active roles of the user allow this.
This is how Galaxy currently behaves. In Galaxy, a library, a library folder and a library dataset are all associated with 3 "library" permissions ( or privileges ): 1) modify library item: Role members can modify this library item 2) add library item: Role members can add library items to this library item 3) manage library permissions: Role members can manage roles associated with this library item These 3 privileges are all "grant" privileges in that if a user has a role that is associated with the permission, the user can perform that action. Roles can be associated with an individual user or a group, and a group can consist of 0 or more users. These 3 library level permissions are all inherited downward in the library hierarchy, so if you set permissions at the library level, any new folder added to the top level of the library will inherit these "library" permissions. The same inheritance scheme works for library folders, so if you add a sub-folder to a folder, the sub-folder will inherit the "library" permissions of it's parent folder. Changing the "library" permissions on a folder will therefore cause all newly added sub-folders to inherit those changed "library" permissions of it's parent. NOTE: this currently only works for newly added folders and library datasets, but we'll soon introduce a feature that will allow you to enforce this inheritance on existing folders and library datasets. A library datasets has 2 "library dataset" permissions in addition to the above 3 "library" permissions: 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 Again, roles can be associated with an individual user or a group, and the "library dataset" permission "manage permissions" is a grant privilege, and has the same behavior as that "library" permission. 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.
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?
My policy should be: each user can do everything with his own dataset.
This is currently possible. If the user is granted the 3 "library" permissions on the folder to which he is adding the dataset, then he will have those 3 "library" permissions on the dataset. The 2 "library dataset" permissions are taken from the user's default permissions for datasets in their histories. The users' "default permissions" are "manage permissions", with no role associated with the dataset "access" permission, making it public by default. These permissions can be changed in the user's preferences ( click the User link in the top menu bar in Galaxy ).
the group of a user can access (view and push it to history) the library.
This is possible if the user that uploads the dataset either leaves it public ( the default ), or associates a group role with the "access" privilege on the library dataset.
a group of bioinformaticians can do everything with allmost all libraries.
This is possible as long as the group has a role that is associated with the various permissions on each library.
How would you implement this in your sheme which requires "all of the roles"? Would I have to create a new role for each combination of user/group/bioinformaticians?
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" permission.
If you would require just "one of the roles", you would simply add 1) the user as a role to the lib (for everything) 2) the group the user is in as a role to the lib (for pushing to history + view if this is implemented) 3) the bioinformatician group as a role to the lib (for everything)
Let me know if my explanations above do not make this clear.
b) An important permission would be to be able to view the item. I played around (maybe not enough) but could not find a way to really hide an item (library, folder, dataset) from the view.
Viewing a library item is managed by the "library dataset" "access" permission. If a folder contains a public library dataset ( call it D1 ), then the library, that folder, and D1 can be seen by any user. However if the same folder contains a library dataset on which only UserA has the "access" permission ( call it D2 ), then UserA will see both D1 and D2, while all other users will see only D1.
c) The little arrow pointing down to bring up the context-menu is very small. It would be helpful if you could maybe make it bigger or turn it into a button.
We'll take this under consideration.
thank you very much, Ido
[1] http://csrc.nist.gov/groups/SNS/rbac/documents/Role_Based_Access_Control-199... _______________________________________________ galaxy-user mailing list galaxy-user@bx.psu.edu http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-user
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.
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?
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" permission. 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. **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. Thank you very much for you time, ido
participants (2)
-
Greg Von Kuster -
Ido M. Tamir