Group sharing permissions of subfolders are not cumulative

[GreenArchon]

Steps to reproduce

1. Be user u1
2. Create user u2 and groups g1, g2
3. Put u2 in g1 and g2
4. Create folders test1, test2 and subfolders test1/subtest1 and test2/subtest2
5. Share folder test1 with g1, then g2, with g1 having share permissions but not g2
6. Share folder test2 with g2, then g1, with g1 having share permissions but not g2

Expected behaviour

u2 can reshare (by link or with someone) test1, test2, as well as test1/subtest1 and test2/subtest2

Actual behaviour

u2 can reshare test1, test2, test1/subtest1 but not test2/subtest2

Server configuration

Database:
MySQL/SQLite
PHP version:
5.4
ownCloud version: (see ownCloud admin page)
8.1.1/master
Updated from an older ownCloud or fresh install:
8.1.0->8.1.1/fresh
List of activated apps:
Enabled:

• files: 1.1.11
• files_sharing: 0.6.3
• files_versions: 1.0.6
• provisioning_api: 0.2
  Disabled:
• encryption
• files_external
• files_trashbin
• user_ldap
• user_webdavauth
  (basically the default clean master one, a bit different on my production version)

Are you using external storage, if yes which one: local/smb/sftp/...
No
Are you using encryption: yes/no
No
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
Yes(LDAP)/No

Note 1: While u2 can't share test2/subtest2, he can click on the sharing icon and has a "Shared with you and the group g2 by u1 - Resharing is not allowed" while doing another share from u1 (say for folder test3) without any sharing permissions at all makes the shared button greyed-out and not clickable.

Note 2:This behavior was also observed back in 8.1.0, I just didn't have the time to investigate/report it before.

Note 3: This only affects sharing, write permission are fine (ie. if at least one of g1, g2 has write permissions, u2 will have them too).

[karlitschek]

@schiesbn

[MorrisJobke]

@schiesbn Ping

[GreenArchon]

Alright, I finally had some time for a git bisect session, which shows 332ea77 / PR #13920 as the problem.

However, since the issue is in the put function (ie. where it gets sent to the db I guess), just fixing it wouldn't fix already existing (malformed) shares. I can confirm this by having compared shares created before 332ea77 (which still works afterwards) to shares created at/after 332ea77 , so I'm really not familiar enough with your code to propose a fix..

@schiesbn any ideas?

[GreenArchon]

A quick look at my db shows that everything seems to be there with the proper permissions, so 332ea77 seems to have uncovered a bug in the way reshare permissions are read more then anything. Indeed, I can now update update the issue with the following steps instead:

Steps to reproduce

1. Have 2 group shares, for the same folder '/test' to groups g1 and g2
2. Have user u1 member of g1 && g2
3. Give group g2 full permissions on the share (oc_share.permissions == 31) and group g1 everything except reshare permission (oc_share.permission == 15)
4. Have g1's oc_share.id < g2's oc_share.id

Expected behaviour

u1 can reshare (by link or with someone) the folder test

Actual behaviour

u1 can't reshare (by link or with someone) the folder test.

Hackingly fix

Changing g1's oc_share.id so that it is > g2's oc_share.id gives user u1 reshare permission.

Note that all of this only affects reshares, and not read/write permissions.

[rullzer]

we should fix this when we move over the sharing internals (better grouping of shares)... assinging to myself so I don't forget.

[PVince81]

PR here #25113

[PVince81]

PR here that might address this #25113

[PVince81]

I retested this in OC 9.0.7 with the provided steps and I couldn't reproduce the issue.
u2 is able to share any of the received folders and subfolders.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.