Clarify responsibilities of share providers and storage providers

[butonic]

While implementing #1368 I noticed a source of confusion. Both, the share providers and the storage providers (can) persist grants. Can, because persisting the grants in either can be disabled in the gateway.

When listing a folder or stating a node the storage provider returns resourceinfo, including a permission set. But what if the grants are only persisted in the share provider? The share providers would have to persist them in a way that they are picked up by the storage provider. Otherwise, the permission set will never reflect the permission the current user has on the resource.

The only types of shares that can be persisted in the storage are user shares, because they can be repersented as acls. Actually, not even they can capture the sharing capabilities of the ocs api, eg. share expiry can only be mapped to plain acls. While additional extended attributes could be used to persist them the public shares and federated shares have even more properties that need to be persisted.

The whole idea of the user, public and ocm share providers is to have a dedicated service for sharing permissions:

• the usershareprovider implements the CollaborationAPI
• the publicshareprovider implements the LinkAPI and
• the ocmshareprovider implements the OcmAPI

That grants can also be persisted in the storage providers is an optional integration to allow end user, that are bypassing reva to see and manage permissions on the underlying storage system. Currently, only eos does this but other storages can also use ACLs. For ocis we plan to have a fuse filesystem that can mount an ocis driver data folder. We could provide additional cli commands to manage public and ocm shares.

If the share providers are responsible for persisting permissions they need to filter the permission set that is returned by the storageprovider. I see several scenarios:

• The current user is the owner (or has the same groupid) of a file. He has all permissions. The storage provider may return only a subset of the permissions, eg. in case the files are readonly. (in this case the ui still needs to allow managing permissions so the user can try to set the write permission). The gateway needs to check if the file is part of a share and apply the filter set of the share. It can only remove permissions, not add permissions.
• The current user is not the owner. This is more tricky, because the storage provider may not know anything about the share. Consider public or ocm links. The permission set cannot express the permissions the current user has on the file. Like in posix, they can only express the permissions the owner has on the files. The gateway needs to check if the file is part of a share and apply the filter set of the share. It can only remove permissions, not add permissions.

The gateway already intercepts the list and stat requests to resolve RESOURCE_TYPE_REFERENCE results. AFAICT that is the same step in the code flow where we need to filter the permissions.

To clarify:

• The permission set in storage provider responses reflects the owner permissions.
• The permission set in gateway responses reflects the current user permissions.