| Summary: | users in LDAP cannot access groups of files users | ||
|---|---|---|---|
| Product: | [Unmaintained] kuser | Reporter: | Daniel Moyne <dmoyne> |
| Component: | general | Assignee: | Szombathelyi György <gyurco> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 2.0.1 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Daniel Moyne
2005-10-09 11:41:34 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.) 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. 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... ) 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. 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! |