Permissions

[atarkowska]

Default permissions were lowered to rw---- in previous versions because of various difficulties with the security system. In order to allow group-sharing, a revamp of the permissions is planned for 4.2. The intention is that all object graphs will belong to a single group, and all objects will have the same read permissions. Mixing objects with different group-ownerships or different read-permissions will not be allowed. Further, a query will only ever return objects belonging to the current group.

Usage / Getting started

import omero
c = omero.client("localhost")
s = c.createSession("root","ome")
q = s.getQueryService()
s.setGroupId(1)
s.setGroup("myLab")
contexts = s.getSecurityContexts()
for ctx in contexts:
    s.setContext(ctx)
    print "# of images in %s:%s=%s" % (type(ctx), ctx.id.val, len(q.findAll("Image", None)))

Definitions

As a part of #1434, the definitions of various concepts related to groups, security, and permissions needs to be more clearly defined.

• "Groups/Labs?"
  • In the code base, these are called ExperimenterGroups
  • In the user interface, these are called TBD
• "Active group"
  • In the code base, the active group is the group set on the session object (session.getDetails().setGroup()) which can be done via session.setSecurityContext() and defines the limit of what can be read or written during a single method invocation. To be logged into multiple active groups at the same time, use multiple sessions.
• "Default group"
  • A user's default group is the first group in the order list of groupExperimenterMaps, i.e. experimenter.getPrimaryGroupExperimenterMap().getParent(). If no other value is provided via the omero.group mechanism, this will be the active group before setSecurityContext() is called.
  • Note: previous to 4.2 there was also a "default" group created on database creation to simplify a first install. This has been renamed in favor of CHANGE_ME
• Admins
  • An admin is a member of the "system" group and has special READ and WRITE permissions.
• PIs/Group owner
  • A PI or group owner is an Experimenter whose membership in an ExperimenterGroup (i.e. has a GroupExperimenterMap link between the two tables) has the "owner" flag set.
  • Group owners have special READ permissions when logged into a group they are a member of, and have special WRITE permissions for some IAdmin methods.
• Private group
  • A group with permissions rw---- is called private, since no one other than admins, group owners, or the owner herself can read objects in such a group
  • Note: in such groups, admins and group owners will NOT be able to write or edit data (no saving rendering settings etc).
• Collaborative group
  • A collaborative group has rwrw-- permissions, so that other members of the group can see and edit objects belonging to other members. The read-only mode allows to decrease the permissions to rwr--- permissions, so that members of the group can only see (but not edit) objects belonging to other members.
• Public group
  • not yet defined.
• TBD: other group types

Code changes

• ServiceFactoryPrx.getSecurityContexts / setSecurityContext - added methods for retrieving and setting the current group or share
• Added GroupSecurityViolation for all violations of group security
• IAdmin.changePermissions called on a group now changes permissions on all objects in that group
• ExperimenterGroup, GroupExperimenterMap and all enumerations are now global objects, and so have no owner, group, or creation event
• Admins no longer have to log in to the "System" group to be recognized as admins
• Groups can have multiple owners

Exceptions

A subhierarchy of SecurityViolation -- GroupSecurityViolation -- has been added. Subclass suggestions include:

• ReadOnlyForAdminGroupSecurityViolation (#1769)
• PermissionMismatchGroupSecurityViolation (#1776)

Note: an alternative would be to add an identifier for local lookup rather than subclassing as request (see #1233/#1649)

Timeline

• Testing phase I starting Week 12/02/10

Notes

Notes from meeting w/ users that will come later

• While accepting that different groups are distinct, in the fullness of time it would be nice to browse multiple groups at once, move images between groups etc.
• Would like to be able to see other users' rendering settings and apply them to your own images on a per-image or per-dataset basis (as before).
• Would like your own rendering settings to be saved on someone else's images, even in read-only mode. "Rendering settings are different" from other data/edits.

NB. Users still unhappy about 'pretty good image' rendering settings being the default on import (prefer min-max). Also report that this has hampered acceptance of OMERO by other users.

original
​http://trac.openmicroscopy.org.uk/omero/wiki/WorkPlan/Permissions

[jmoore]

See #320. Moved to a requirement for 4.3

[jmoore]

Description from insight requirement #3337 (duplicate)

Default permissions were lowered to rw---- in previous versions because of various difficulties with the security system. In order to allow group-sharing, a revamp of the permissions is planned for 4.2. The intention is that all object graphs will belong to a single group, and all objects will have the same read permissions. Mixing objects with different group-ownerships or different read-permissions will not be allowed. Further, a query will only ever return objects belonging to the current group.

[jmoore]

My plan would be to add all the open stories here to public data (#1733) and close this requirement if that works for everyone.

[jmoore]

Moved all remaining stories to #1733; closing.