User Story #182 (closed)
Opened 18 years ago
Closed 18 years ago
Users want to be able to set umasks on a per-session basis.
Reported by: | jamoore | Owned by: | jamoore |
---|---|---|---|
Priority: | critical | Milestone: | 3.0-M3 |
Component: | Security | Keywords: | profiles, story114, iteration4 |
Cc: | Story Points: | n.a. | |
Sprint: | n.a. | Importance: | n.a. |
Total Remaining Time: | n.a. | Estimated Remaining Time: | n.a. |
Description
Really advanced users...
This would be the first use case for an ExperimenterProfile? (similar to the bash .profile or .bashrc). It's not currently needed, but would allow for a good deal of variability.
In the case of umasks, the class-umask could either overwrite or be OR'd with the system umask and then XOR'd against FFFF (we currently use four bits -- see #180).
Change History (8)
comment:1 Changed 18 years ago by jmoore
- Milestone changed from Unscheduled to 3.0-M3
- Priority changed from minor to critical
- Status changed from new to assigned
comment:2 Changed 18 years ago by jmoore
- Keywords iteration4 added
comment:3 Changed 18 years ago by jmoore
#307 details the need for a workaround.
comment:4 Changed 18 years ago by jmoore
r895 fulfills this requirement by no longer having Permissions instantiated in all Details instances. (Null Permissions, however, produced the Hibernate bug described in #307) This allows users to either (a) leave them null and take the umask default or (b) set the permissions and have them used on the backend (overrides umask).
Umasks are set on ServiceFactory and are resent on each call (as outlined in Omero+Security.
Once #307 is resolved, the fixing of nulls should move from UpdateFilter to BasicSecuritySystem.transientDetails and the reference to Permissions.Flag.SOFT in BasicSecuritySystem.managedDetails should be removed.
The nulling of Permissions required some reworking of existing tests. There are also new tests in the ome.client.itests.sec package for testing umasks.
comment:5 Changed 18 years ago by jmoore
r896 extends the tests. (Also adds a un-related testng suite, that's generally useful, though)
comment:6 Changed 18 years ago by jmoore
r900 filters the SOFT flag off of all permissions. This may or may not be the best long-term usage (i.e. there may be a reason to allow permissions to remain "SOFT" in the DB), but in the short-term, it makes things a bit cleaner.
comment:7 Changed 18 years ago by jmoore
r901 fixes my whoops.
comment:8 Changed 18 years ago by jmoore
- Resolution set to fixed
- Status changed from assigned to closed
- Summary changed from Users want to be able to set umasks on a per-class basis. to Users want to be able to set umasks on a per-session basis.
Seems to be stable. Changing per-class to per-session. The per-class requirement can be written up (much) later.
This has been written up to some extent under Omero+Security on the tiki. Probably will start without the per-class basis style but rather per-session basis.