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

[base]

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.

[Nicklas Nordborg]

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.

[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.

[Nicklas Nordborg]

(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.