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"

Bug #293 (closed)

Opened 18 years ago

Closed 18 years ago

User can't change Permission once permissions set to ---------.

Reported by: jamoore Owned by: jamoore
Priority: critical Cc:
Sprint: n.a.
Total Remaining Time: n.a.

Description

Doing the following:

   Thumbnail tb = ... ;
   serviceFactory.getAdminService().changePermissions(tb, Permissions.EMPTY);
   serviceFactory.getAdminService().changePermissions(tb, Permissions.DEFAULT);

fails with the exception:

  ome.conditions.SecurityViolation: Cannot read ome.model.display.Thumbnail

Change History (7)

comment:1 Changed 18 years ago by jmoore

This may require @RunAs functionality, specifically a way to track who actually did the action which was run as root.

comment:2 Changed 18 years ago by jmoore

r885 fixes this. The implementation switches the currentUserIsAdmin flag of the SecuritySystem to true within a try/finally block. All event tracking should be unaffected (i.e. the user seen is still the logged in user and not root or similar).

The security tests (specifically client-side AdminTest) will need to check for holes.

comment:3 Changed 18 years ago by jmoore

r886 makes this actualy work. heh.

comment:4 Changed 18 years ago by jmoore

  • Keywords changed from iteration4, permissions, iadmin to iteration5, permissions, iadmin

Moving to iteration5 for testing.

comment:5 Changed 18 years ago by jmoore

  • Resolution set to fixed
  • Status changed from new to closed

Seems to work fine. Closing. In general, users must be aware that setting anything to NON-USER-READ (e.g. ------, or -w----) is paramount to shooting oneself in the foot.

comment:6 Changed 18 years ago by jmoore

  • Resolution fixed deleted
  • Status changed from closed to reopened

r959 breaks this fix. Seems like their are some conflicting requirements.

comment:7 Changed 18 years ago by jmoore

  • Resolution set to fixed
  • Status changed from reopened to closed
r961 settles the requirments dispute by manually checking for user
admin. However, as #365 points out, this logic needs to be brought in sync with the allowUpdate logic of the security system. Reclosing and referring to #365.
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.62124 sec.)

We're Hiring!