Opened 14 years ago

Closed 14 years ago

#929 closed defect (fixed)

An existing share to Everyone may block sharing an item to others if the user lacks SHARE_TO_EVERONE permissions

Reported by: base Owned by: Nicklas Nordborg
Priority: minor Milestone: BASE 2.6
Component: core Version:
Keywords: Cc:

Description

If I am a normal user without "share to Everyone" permissions, it is possible that some of my Items have previously been shared to Everyone by a superuser. If I later try to share these Items to another user or project, I am forced to remove the "Everyone" share because I don't have permission to "re-share to Everyone" which I guess is what is happening under the hood.

This may be a "core" issue. I haven't gone into the source code this time.

many thanks, Bob.

Change History (5)

comment:1 Changed 14 years ago by Nicklas Nordborg

Component: webcore
Milestone: BASE 2.x+

I think this is a side effect of how the permission system works. When you are changing the permissions for an item, what really happens is that a new ItemKey? is created and the permissions are set on that. From the core side, it is not possible to see any difference from permissions that existed before and permissions that are new. In a sense, all permissions are new. Thus, if the user doesn't have the SHARE_TO_EVERYONE permission, the item can no longer be shared to the everyone group.

I'll leave this ticket open in case we can come up with a solution. Until then, the workaround is to give the user SHARE_TO_EVERYONE permission.

comment:2 Changed 14 years ago by Nicklas Nordborg

Hmm... I think I might have a working solution. The first thing that happens when sharing an item is that the existing permissions are copied into three objects: UserPermssions?, GroupPermissions? and ProjectPermissions?. New and changed permissions are set on those three objects which are then passed back to the core, which uses the information to create new keys. It would be possible to make a second copy of the original permissions in the three objects and just let the core accept the Everyone group if the permissions didn't change.

This introduces a security problem were it would be possible to bypass the SHARE_TO_EVERYONE permission check by subclassing the GroupPermissions? object and have it report that the share was there to begin with. The solution to this is to make the classes final. This is in it's turn an incompatible API change that will break code that already subclasses any of the three classes.

comment:3 Changed 14 years ago by Nicklas Nordborg

Milestone: BASE 2.x+BASE 2.6
Owner: changed from everyone to Nicklas Nordborg
Status: newassigned

comment:4 Changed 14 years ago by Nicklas Nordborg

Summary: Possible share to Everyone bugAn existing share to Everyone may block sharing an item to others if the user lacks SHARE_TO_EVERONE permissions

comment:5 Changed 14 years ago by Nicklas Nordborg

Resolution: fixed
Status: assignedclosed

(In [4141]) Fixes #929: An existing share to Everyone may block sharing an item to others if the user lacks SHARE_TO_EVERONE permissions

There was no need to make the entire class final, only some of the internal methods. In the web client the checkboxes are disabled for the Everyone group if the user lacks share to everyone permission.

Note: See TracTickets for help on using tickets.