New builds not appearing on Drone

labkode · December 10, 2020, 2:05pm

Since yesterday night we have seen that new PRs don’t run the Drone check.
The webhook to Drone cloud is triggered successfully ( attached image ).

This is one of the latest PRs that didn’t trigger the build:

github.com/cs3org/reva

Enhancement: calculate and expose actual file permission set

cs3org:master ← butonic:share-permissions-and-resource-permissions

opened 01:50PM - 10 Dec 20 UTC

butonic

+1788 -1110

Instead of hardcoding the permissions set for every file and folder to `ListCont…ainer:true, CreateContainer:true` and always reporting the hardcoded string `WCKDNVR` for the WebDAV permissions we now aggregate the actual cs3 resource permissions in the storage drivers and correctly map them to ocs permissions and webdav permissions using a common role struct that encapsulates the mapping logic. - refactor the create*Share methods to use the same stat - use a common permissions check to prevent users from sharing with permissions they don't have - map between share role, cs3 resource permissionset, ocs permissions - [x] the mapping needs to be simplified by mapping everything to roles - [x] we can bring back legacy ocs permissions by mapping them to all legacy role combinations and finding corresponding mappings in cs3 permission sets. - refactor error handling - [ ] ~~use ocdav.HandleErrorStatus in more places~~ left for another PR I already touched too many things. - fix storages and calculate permissions by reading the grants in the path instead of hardcoding `ListContainer:true, CreateContainer:true` - [x] ocis - [ ] ~~eos~~ I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR. - [ ] ~~local~~ I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR. - [ ] ~~s3~~ I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR. - [ ] ~~owncloud~~ I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR. should fix - [QA] Resharing is always allowed even when we do not add that permission https://github.com/owncloud/ocis/issues/552 - [QA] Re-Sharer can increase permissions https://github.com/owncloud/ocis/issues/893 - cannot get ocs:share-permissions via WebDAV https://github.com/owncloud/ocis-reva/issues/47 - [EOS] Cannot access public links https://github.com/owncloud/ocis-reva/issues/315 - [EOS] share not created with default permissions https://github.com/owncloud/ocis-reva/issues/316 related - upload-only public link does not refer to files-drop page, nor are the permissions enforced https://github.com/owncloud/ocis/issues/723 - path and other information are not shown if a share does not have "read" permission https://github.com/owncloud/ocis/issues/762 - various sharing settings cannot be set https://github.com/owncloud/ocis-reva/issues/41 - Some failing tests with Webdav custom properties https://github.com/owncloud/ocis-reva/issues/217 - Different propfind response compared with core https://github.com/owncloud/ocis-reva/issues/236 - Sharing seems to work but does not work https://github.com/owncloud/ocis-reva/issues/243 - Accessing non-existing public link should return 404, not 500 https://github.com/owncloud/ocis-reva/issues/290 - Public link enforce permissions https://github.com/owncloud/ocis-reva/issues/292 - [OCIS-Storage] etags don't change for a share receiver https://github.com/owncloud/product/issues/243 - [OCIS-storage] resharing doesn't works https://github.com/owncloud/product/issues/265 - [OCIS] share permissions not enforced https://github.com/owncloud/product/issues/270 - [OC Storage] etags are not updated on file operations https://github.com/owncloud/product/issues/279 @labkode eos, localfs, and the other storages need to return a proper PermissionSet for the logged in user so the ocs api can actually return the right ocs permissions. For the ocis I implemented a `ReadUserPermissions()` that aggregates the permissions on all segments of the path. `ReadUserPermissions()` is called in `GetMD()` and `ListContainer()`. It should be possible to aggregate the permission set for the other storages in a similar manner. Can eos return the acl or permissions for the current user in the fileinfo or is that another call. ... well it might not be necessary if eos really cannot store acls on files directly (only via fuse richacls). Another option might be to push setting the permission set to the gateway. it could use the storage registry to fill in the permissions without having to stat every path segment, because it can look at the mount points of shares. Anyway, this PR currently tries to check if the current user is the owner and returns all permissions if that is the case. This works on eos, ocis, local and owncloud AFAICT. not on s3, yet. For shared folders the ocis driver aggregates the permissions. I did not do thet for the other storages yet, but would start implementing it in the same way, unless you have a better idea how to do it more efficiently. For now I want to make it work. Profiling to make it fast comes later.

Any hint on what could be the problem?

Thanks in advance

labkode · December 11, 2020, 7:37am

@bradrydzewski, any info?

jones2026 · December 16, 2020, 6:01pm

@labkode is this still occuring for you? builds on my end seem to be working fine still.