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