Task #1769 (closed)
Permissions : Handle admin/PI viewing/annotating in private group
| Reported by: | jamoore | Owned by: | jamoore |
|---|---|---|---|
| Priority: | major | Milestone: | OMERO-Beta4.2 |
| Component: | Security | Keywords: | n.a. |
| Cc: | atarkowska, jburel | Remaining Time: | n.a. |
| Sprint: | n.a. | Resources: | n.a. |
| References: | n.a. | Referenced By: | n.a. |
Description (last modified by jmoore) (diff)
This ticket is a part of #1434
A system or group administrator who views or attempts to annotate data belonging in a private or non-member group may break group-based security settings for the owner.
Options:
- make objects belong to admins public
- -1 since objects would appear as disembodied hands for non-owners.
- make annotations/rendering settings/thumbnails belong to the owner (or the group in the case of a shared group which the admin is not a member of))
- -1 since objects would suddenly appear to the owner as his/her own.
- make the session read-only (with special handling for rendering settings and thumbnails)
- ?
- add a flag or other marker to allow user-reading of such data.
- Dicussion: an "AsAdmin" flag would mark any object which was created via admin privilege, so that when a PI annotates in a shared group, there is no flag but in a private group, there is. Then if the PI-user is removed as an owner or the admin is removed from the "system" group, the object would still be marked as special.
- Would need special handling on down- (and up-?) grades of permissions.
- Is this identical to making public above? (probably unless we record the owner of the linked object in a new column)
- ???
References
| Referenced by: | |||
|---|---|---|---|
|
Change History
comment:6 Changed 3 years ago by jmoore
Decide Feb 04 that for the first instance, read-only sessions for root/PI is viable.
comment:7 Changed 3 years ago by jmoore
- r6050 - Disabling INSERT/UPDATE of non-system-types in private group …
- r6049 - Rolling back addition of Permissions.ADMIN
- r6048 - Attempting to add ADMIN permissions flag (includes …
- r6047 - Filling omero.model.EventContext? with groupPermissions
- r6046 - Added check for critical graph additions
This implements the "no admin/pi write in a private group" logic. The current exception thrown is GroupSecurityViolation which will likely need to be improved.
comment:8 Changed 3 years ago by jmoore
- r6072 - ticket:1769 - Assuming ticket:1698 won't apply if not setting LOCK
- r6071 - ticket:1769 - First attempted using currentState to workaround ticket:1698
- r6070 - ticket:1769 - Loosened restrictions on INSERT/UPDATE/DELETE in private …
comment:9 Changed 3 years ago by jmoore
- r6106 - Automatic re-use of rendering defs for admin … ( shoola:ticket:1157)
- r6105 - Added ReadOnlyAdminGroupSecurityViolation
comment:10 Changed 3 years ago by jmoore
- Status changed from new to closed
- Resolution set to fixed
Closing this ticket since the functionality that we are shooting for is in place according to [WorkPlan/Permissions]. There are certainly still cases of things that can be improved like the automatic rendering settings handling in shoola:ticket:1157, but we can handle those on a case by case basis.
