| Summary: | Domain users and groups are not recognized (??? displayed) | ||
|---|---|---|---|
| Product: | [Applications] krusader | Reporter: | Ivo Smelhaus <ismelhaus> |
| Component: | general | Assignee: | Krusader Bugs Distribution List <krusader-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | davide, krusader-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | Git | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Dolphin-home
Krusader-home dolphin+krusader-properties |
||
|
Description
Ivo Smelhaus
2021-06-24 16:47:45 UTC
The file properties window is shared with Dolphin, do you see the correct data when opened from Dolphin? Created attachment 141008 [details]
Dolphin-home
Created attachment 141009 [details]
Krusader-home
Created attachment 141010 [details]
dolphin+krusader-properties
I've got the point with sharing, but in a real world sometimes the things work differently :-) alfresco + ivo are local users, others are domain users. It seems you don't have acl enabled in Krusader, what is the output of ldd /usr/bin/krusader | grep acl ldd /usr/bin/krusader | grep attr given that Krusader is installed in /usr/bin, you can find it with which krusader. If you compiled Krusader from sources, you should look in the configuration if you see "Found ACL support" Here are:
ldd /usr/bin/krusader | grep acl
libacl.so.1 => /usr/lib/x86_64-linux-gnu/libacl.so.1 (0x00007f3762563000)
ldd /usr/bin/krusader | grep attr
(nothing)
----
Yes, it's compiled from sources. In which config. should it be found?
---
note 1:
I am using Krusader already some years and at least one year compiled and all the time connected to domain. And it worked until I've changed pbiso to sssd together with some settings like ldap_id_mapping. (but no guarantee, that this was the only change)
note 2:
...If I try hard to remember, that I think, I saw this "???" already few times before, but quit and open Krusader again, it was already fine.
note 3:
on another PC which still uses pbiso and Krusader from repo works fine and ldd acl/attr gives the same result.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! Sorry for changing state waitingforinfo -> reported.
The truth is, that I provided most of requested info and asked for better specification for the last piece and am still waiting for that.
> Yes, it's compiled from sources. In which config. should it be found?
Logically, the requested info was not provided completely, but I as a reporter can't do anything with it. So, if this in KDE means, that the bug is resolved, which is not true at all, I am forced to claim, the full info was provided, because it's closer to reality. ;-)
In the meantime I switched to Kubuntu 22.04 and compiled Krusader using the git:master. The behavior didn't changed. So I spent some time with looking into logs etc. and all ACl and ATTR infos were OK.
From user point of view the ACL and ATTR displaying and manipulations work without any problem with local users.
With AD users (using sssd) there are some problems:
1. if the ad-user or ad-group is an owner or a group then in list view or in permission settings are displayed the reported ???
(in Dolphin they are displayed correctly)
2. if the ad-user or ad-group is a listed user or group (e.g. setfacl -m u:ad-user-x:rwx), then they are displayed correctly (i.e. their names) and their permissions could be set correctly as well
3. non of them are listed, so they can't be added
(in Dolphin is the same)
4. if they are written in the owner or group field, they are set correctly, but not displayed (even if set, the ??? are displayed again)
(Dolphin uses list instead of text field, so they can't be added at all)
The root of this problem:
1. The AD users/groups could be queried but were not listed. So e.g. `getent passwd ad-user-x` gave the result but `getent passwd` did'nt listed them
2. If the policy is changed through setting of `enumerate = true` in /etc/sssd/sssd.conf , then everything works as expected.
It looks like, that Krusader reads the listed users and groups and then only looks for uid into this lists and if there isn't found, displays the ??? but Dolphin just makes the second attempt. Am I right?
The solution:
0. Mention the problem in Known Issues with the workaround by "enumerate = true" which is the best one for small domains.
1. Get the same result like Dolphin by trying to get name for given uid directly if not found in the list and display uid instead of ??? if not found. - It makes 80% improvement from user point of view.
2. To add the directly queried ad-users and ad-groups into the list, so that these could be used for other files/directory setting. ( 80% -> 95%)
3. Search in AD users/groups ....
|