LDAP admin in neo4j is not administrator for GDS

[MbICJIb]

Describe the bug Administrators of neo4j db, authenticated by LDAP, aren't administrators for GDS. So, they can't see and use graph projections of any other user.

GDS version: 1.8.0 Neo4j version: 4.3.8 Operating system: Oracle Linux 7 Enterprise

Steps to reproduce the behavior:

• Create some graph projection like call gds.graph.create('TestProjection','*','*');
• From this user you should see it by command call gds.graph.list();
• Log in to neo4j as any another LDAP user, which has admin privilegies and try to see if that projection exists by the same command: call gds.graph.list();

Expected behavior LDAP admin should have the same privileguies as local admins. According to first paragraph of page So, second user should see all graph projections.

[Mats-SX]

Hello @MbICJIb and thanks for reaching out to us. I apologise in advance for the late reply.

In order for GDS to consider a user an administrator, the user must have been granted a role with the exact name admin. This supports the basic Neo4j setup where there is a built-in role called admin.

When using an external security system for authentication/authorization in conjunction with GDS's notion of administration, a role-mapping may be required. How to configure that is thoroughly described in the relevant part of the Neo4j Operations Manual. Make sure that the LDAP group corresponding to administrators is mapped to the Neo4j built-in role of admin.

Here, I am assuming that this is not the case. If I am wrong, and such a role mapping is indeed configured, please tell and we will make a deeper investigation into the cause.

Best regards Mats

[MbICJIb]

Hello, @Mats-SX !

As I understand, we use not LDAP, but OpenLDAP or it's analogue.

There is a part of the config and image file from the browser in attachment. So, we associate with neo4j role admin not roles from LDAP, but users by their names. Neo4j recognize us as admin and we can make all actions, what admin can, except GDS actions.

Please, try to solve my problem, or, maybe, there is any workaround to execute GDS functions and procedures as admin to share results with all other admins in graph.

[Mats-SX]

Hello @MbICJIb. Thanks for persisting on this issue. I've double-checked this and it doesn't seem to work the way it should. We need to investigate further, but I cannot exclude the chance of this being a bug at the moment. Our tests do claim that this works, but something must be amiss.

[Mats-SX]

@MbICJIb What is the output of running

CALL gds.debug.sysInfo()

[MbICJIb]

Hello, @Mats-SX !

We use neo4j 4.3.8 and gds 1.8.0 on our production server, as I wrote earlier, but on test server we try to use lastest version of neo4j and 2.0.4 version of gds, that gives the same bug. Admin users can't see projections created by other users.

Output of that command:

number | key | value
-- | -- | --
1 | "gdsVersion" | "1.8.0"
2 | "gdsEdition" | "Unlicensed"
3 | "neo4jVersion" | "4.3.8"
4 | "minimumRequiredJavaVersion" | "11"
5 | "featurePreAggregation" | false
6 | "featureSkipOrphanNodes" | false
7 | "featureMaxArrayLengthShift" | 28
8 | "featureKernelTracker" | false
9 | "featurePropertyValueIndex" | false
10 | "featureParallelPropertyValueIndex" | false
11 | "featureBitIdMap" | true
12 | "featureUncompressedAdjacencyList" | false
13 | "featureReorderedAdjacencyList" | false
14 | "buildDate" | "2021-11-30_21:09:02"
15 | "buildJdk" | "11.0.13+8 (Eclipse Adoptium)"
16 | "buildJavaVersion" | "11.0.13"
17 | "buildHash" | "8a3ce543e9e3c85a4da348a686ed686ebd6ca671"
18 | "availableCPUs" | 4
19 | "physicalCPUs" | 4
20 | "availableHeapInBytes" | 33285996544
21 | "availableHeap" | "31 GiB"
22 | "heapFreeInBytes" | 19570519944
23 | "heapFree" | "18 GiB"
24 | "heapTotalInBytes" | 33285996544
25 | "heapTotal" | "31 GiB"
26 | "heapMaxInBytes" | 33285996544
27 | "heapMax" | "31 GiB"
28 | "offHeapUsedInBytes" | 553791416
29 | "offHeapUsed" | "528 MiB"
30 | "offHeapTotalInBytes" | 595423232
31 | "offHeapTotal" | "567 MiB"
32 | "poolCodeheapNonNmethodsUsedInBytes" | 2629248
33 | "poolCodeheapNonNmethodsUsed" | "2567 KiB"
34 | "poolCodeheapNonNmethodsTotalInBytes" | 2818048
35 | "poolCodeheapNonNmethodsTotal" | "2752 KiB"
36 | "poolMetaspaceUsedInBytes" | 392715928
37 | "poolMetaspaceUsed" | "374 MiB"
38 | "poolMetaspaceTotalInBytes" | 426905600
39 | "poolMetaspaceTotal" | "407 MiB"
40 | "poolCodeheapProfiledNmethodsUsedInBytes" | 65226368
41 | "poolCodeheapProfiledNmethodsUsed" | "62 MiB"
42 | "poolCodeheapProfiledNmethodsTotalInBytes" | 65601536
43 | "poolCodeheapProfiledNmethodsTotal" | "62 MiB"
44 | "poolCompressedClassSpaceUsedInBytes" | 56678400
45 | "poolCompressedClassSpaceUsed" | "54 MiB"
46 | "poolCompressedClassSpaceTotalInBytes" | 63070208
47 | "poolCompressedClassSpaceTotal" | "60 MiB"
48 | "poolG1EdenSpaceFreeInBytes" | 8891924480
49 | "poolG1EdenSpaceFree" | "8480 MiB"
50 | "poolG1EdenSpaceTotalInBytes" | 20929576960
51 | "poolG1EdenSpaceTotal" | "19 GiB"
52 | "poolG1EdenSpaceMaxInBytes" | -1
53 | "poolG1EdenSpaceMax" | "N/A"
54 | "poolG1OldGenFreeInBytes" | 10678595464
55 | "poolG1OldGenFree" | "10183 MiB"
56 | "poolG1OldGenTotalInBytes" | 12322865152
57 | "poolG1OldGenTotal" | "11752 MiB"
58 | "poolG1OldGenMaxInBytes" | 33285996544
59 | "poolG1OldGenMax" | "31 GiB"
60 | "poolG1SurvivorSpaceFreeInBytes" | 0
61 | "poolG1SurvivorSpaceFree" | "0 Bytes"
62 | "poolG1SurvivorSpaceTotalInBytes" | 33554432
63 | "poolG1SurvivorSpaceTotal" | "32 MiB"
64 | "poolG1SurvivorSpaceMaxInBytes" | -1
65 | "poolG1SurvivorSpaceMax" | "N/A"
66 | "poolCodeheapNonProfiledNmethodsUsedInBytes" | 36541952
67 | "poolCodeheapNonProfiledNmethodsUsed" | "34 MiB"
68 | "poolCodeheapNonProfiledNmethodsTotalInBytes" | 37027840
69 | "poolCodeheapNonProfiledNmethodsTotal" | "35 MiB"
70 | "freePhysicalMemoryInBytes" | 18283954176
71 | "freePhysicalMemory" | "17 GiB"
72 | "committedVirtualMemoryInBytes" | 60707713024
73 | "committedVirtualMemory" | "56 GiB"
74 | "totalPhysicalMemoryInBytes" | 143365267456
75 | "totalPhysicalMemory" | "133 GiB"
76 | "freeSwapSpaceInBytes" | 2147479552
77 | "freeSwapSpace" | "2047 MiB"
78 | "totalSwapSpaceInBytes" | 2147479552
79 | "totalSwapSpace" | "2047 MiB"
80 | "openFileDescriptors" | 586
81 | "maxFileDescriptors" | 4096
82 | "vmName" | "OpenJDK 64-Bit Server VM"
83 | "vmVersion" | "11.0.12+7-LTS"
84 | "vmCompiler" | "HotSpot 64-Bit Tiered Compilers"
85 | "containerized" | false
86 | "dbms.security.procedures.unrestricted" | "apoc.*,gds.*"
87 | "dbms.memory.pagecache.size" | "60g"
88 | "dbms.tx_state.memory_allocation" | "ON_HEAP"
89 | "dbms.memory.off_heap.max_size" | 2147483648
90 | "dbms.memory.transaction.global_max_size" | 0
91 | "dbms.memory.transaction.max_size" | 0

[Mats-SX]

@MbICJIb Thanks for reaching back. We did do a thorough investigation following my previous re-opening of the issue, found the bug and fixed it. The fix is included in GDS 1.8.8 which should be the easiest for you to upgrade to. Apologies for not reaching back to this issue on the event of release.

While 1.8 is a fully live version that we will keep on supporting and fixing bugs for, we have set a final end of life date for it at September 22 this year. As such, I recommend that you attempt upgrading to our latest version 2.1.5 (alternative link at Neo4j Download Center), which includes many additional features and improvements.

Thanks for your collaboration and persistence!

All the best Mats