Sharing a file with 'same first name' LDAP users crashes for the second user #20083
Milestone
Comments
|
@blizzz @rullzer @cmonteroluque @DeepDiver1975 |
|
Regression ? Or did it never work before ? |
|
Weird infinite loop here: It doesn't even make sense, it's just reading some config values: https://github.com/owncloud/core/blob/v8.1.4RC1/lib/private/legacy/config.php#L59 |
|
And here the location where the share.php error happens: https://github.com/owncloud/core/blob/v8.1.4RC1/core/ajax/share.php#L313 Hope this helps a bit for debugging... |
|
LDAP conf is missing |
|
Also, the sharing config (admin page) is missing |
|
Would also be good to see the call from the network console. That share.php error seems to tell that the client didn't pass the correct "itemShares" value. |
|
Works for me 😜
All usernames start with |
|
The "Array to string" conversion seems to be unrelated. I am able to reproduce it simply by having 1-2 shares existing in the list then invoking the autocomplete, without LDAP!. But that doesn't lead to any issues. |
|
Also tried with restricting sharing to within the group. But also this does work. Anyway, without the information requested above it's like looking for the needle in the haystack. The function nesting happens in reading a config value which is so common and happens in so many places → a backtrace would be handy as well. |
|
"Array to string conversion" case also happens on master. |
|
Raised "Array to string conversion" issue separately #20095 |
|
From the original log it seems that "Array to string" conversion happened several times within the same request, and it was followed by the infinite loop. The number of occurrences of "Array to string conversion" message is the same as the number of users appearing in the list aka the number of users to exclude. But the screenshot only shows one user, which means it is likely that the screenshot doesn't match the log. |
|
Gif of how to reproduce the issue:
Notice that the Internal Username Attribute used is 'uid' |
|
Go it reproduced against @davitol's LDAP server. It's the infinite loop: From what I understand the workflow is as follows:
Need to debug further into the second call |
|
The place where the logger is called is here: https://github.com/owncloud/core/blob/v8.1.4RC1/apps/user_ldap/lib/access.php#L1482 This message is repeated several times in the log, so I expect it to work usually. But at some point it starts to bug as we can see on the stack trace above. |
|
Ok I think I understand what is happening. The logging error is only a side effect. Bascially, the search is working recursively for some reason, so the size of the stack increases with every next search call. At some point, calling the logger makes the code reach the maximum stack size. It has nothing to do with the logger, it could be happening to any other piece of code that might have deeper calls. From what I remember, @blizzz said there is nothing that can be done to make the paged search non-recursive ? The reason why we hit this limit here is because there are lots of "alliyah" users on this specific LDAP server. |
|
So I don't think this is a blocker for 8.1.4. It's an old issue with no possible solution. @blizzz can you comment ? |
|
There are 352 entries that start with "alliyah" in the test LDAP server. |
|
We need this for pagination, if we want to read a result set somewhere in the middle of LDAP, as it is how LDAP Paged Resulsts work. However, now I think we could rearrange that – but this will again change a core part of the backend and I would not want to do that for a maintenance relase without urge. Quitting after a nesting level of 100 is also xdebug related, it should not be installed on production systems. The limit is higher there. But there is a different problem hidden. With @davitol s LDAP server, I also see this in my log that we are doing LDAP searches with a limit of 1, but seemingly for all possible users. This seems to be wrong. I continue to find out what is happening here. |
So, apparently not a catastrophe, I like to investigate this anyway and come with a conclusion. |
Not a problem. This is reading the displayname, which usually is cached anyway. Only in my case i had the cache life time set to a small number for testing reasons. In production this is not an issue. The search action would not go for just one user, but for the limit it gets by parameter. So in sharing it happens that the call However this case became noticable since we requested 200 instead of 15 users in the share dialogue, which in constellations like this just takes longer and causes more of recursion cycles. Conclusion: This is highly unlikely to happen on production systems, thus not blocking. I would like to look into resolving the recursions, but since it's a fundamental change I'd prefer to do that only for 9.0. |
ghost
added this to the
|
@PVince81 yes, let's do it |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to reproduce
1.- Share a file with a LDAP user (e.g. aaliyah_adams)
2.- Try to share the same file with another LDAP user 'same first named' (e.g. aaliyah_kulas)
Expected behaviour
The file should be shared
Actual behaviour
An error 500 occurs when autocompleting the second LDAP user name for sharing
Server configuration
Operating system:
Ubuntu 14.04
Web server:
Apache
Database:
MySQL
PHP version:
5.5.9
ownCloud version: ownCloud Enterprise Edition 8.1.4 RC1 (daily) Build:2015-10-26T03:40:45+00:00 5062007
Updated from an older ownCloud or fresh install:
Fresh
List of activated apps: LDAP
The content of config/config.php:
Are you using external storage, if yes which one: local/smb/sftp/...
No
Are you using encryption:
No
Logs
Client configuration
browser
Firefox and Chrome
NOTE: Same behaviour in Master branch
The text was updated successfully, but these errors were encountered: