Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

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

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.

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.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.67807 sec.)

We're Hiring!