Bug 114105 - users in LDAP cannot access groups of files users
Summary: users in LDAP cannot access groups of files users
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kuser
Classification: Unmaintained
Component: general (show other bugs)
Version: 2.0.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Szombathelyi György
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-09 11:41 UTC by Daniel Moyne
Modified: 2025-02-07 14:30 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Moyne 2005-10-09 11:41:34 UTC
Version:           2.0.1 (using KDE 3.4.2, Kubuntu Package 4:3.4.2-0ubuntu0hoary2 )
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)
OS:                Linux (i686) release 2.6.10-5-k7

Now Kuser supports LDAP database but I have some comments :

(1) in LDAP setup I experienced some problems in setting proper parameters when setting LDAP access as for user field instead of setting full DN name (cn=admin,dc=...,dc=...,dc=...) I used short one (cn=admin) ; moreover doc was not available ; to clarify I propose to do the following :
- use label "User DN" instead of "User" and add selectable option "append base DN" which will clarify what is to be done without getting the doc !
- clarify "System" choice along with "file" and "LDAP" choices as as far as I understand for users and groups everything is systemwise !

(2) Now regarding setting users and group in LDAP database there is a problem as both "file" and "LDAP" database are considered as independant at this level : for example :
- a created user or group may have the same uid or gid as a user from "file" database !
- it is not possible to add for an "LDAP" group users that belong to "file" users ; in short words cross recognition is not possible.

Of course the same appends for "file" users and groups that ignore users and groups of LDAP database !

The only way to properly set users and groups of both "file" and "LDAP" databases is to manually edit users and groups to set attributes correctly.
Comment 1 Szombathelyi György 2006-10-08 00:18:20 UTC
Implementing this requires a rather large refactoring of KUser methods which handles backends. Now internally KUser works with only one backend at a time, this requires writing a proxy class which distributes the data between backends based on uid/gid ranges. I'm thinking of implementing this for KDE4, but that depends on my time and lazyness :)
The "System" backend shows everything, but this is cheating...the unix nss libraries allows the listing all users, but there's no add/del/modify interface in them, so writing cannot be enabled on this backend. (That's why standard adduser & co. does work only on /etc/passwd and friends.)
Comment 2 Daniel Moyne 2006-10-08 11:07:18 UTC
Thanks for the answer ; what is even stranger is that even if I add a Ldap user to a unix group by editing directly "group" and "group-" files I do not see this modification when editing this particular group with KUser which is in the present status of KUser very misleading !

I do not understand why you say that this requires very large refactoring as basically modifications made by hand as I did are validated by the system which is what matters the most ; for me this is simply a matter of showing for KUser what is actually on by processing globally users and groups whichever data base they belong to ; of course the application should show which data base they belong to by for example either using different color to discriminate in an alphabetical list or listing first unix users and then Ldap users in a vertical list  ; separating user and group handling by choosing the data source first is by no mean the way to go ; in "Configuration" you simply setup the various data sources one by one but you do not select them one by one in "General" for edition as in present version ; after a modification is required by user it is implemented as done now data base by data base so basically no difference but everything is shown afterwards as implemented in both global list of users and groups with for example proposed features.
Comment 3 Szombathelyi György 2006-10-08 12:53:59 UTC
Ok, maybe not "very large" refactoring needed, but need to write the above mentioned proxy class, modify the methods that deal with the seperate backends now to use the proxy class, modify the config interface to allow selecting more backends with uid-gid ranges, ask the user when he wants to create a new user which backend he would like to use. Nice task for KDE4 :) 
Don't expect this in KDE3 (from me at least... )
Comment 4 Justin Zobel 2021-03-10 00:32:39 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 5 Nate Graham 2025-02-07 14:30:42 UTC
kuser no longer exists as a separate thing and hasn't for several years; it's relevant functionality now exists as the Users page in System Settings. If you experience an issue with that page, or want to request a new feature for it, feel free to open a new bugzilla ticket about the matter at https://bugs.kde.org/enter_bug.cgi?product=systemsettings&component=kcm_users.

Thanks folks!