| Summary: | pam_sss(sshd:account): Access denied for user smith: 4 (System error) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fujisan <fujisan43> | ||||||||
| Component: | libsemanage | Assignee: | Petr Lautrbach <plautrba> | ||||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 24 | CC: | abokovoy, dwalsh, fujisan43, jhrozek, lslebodn, mgrepl, mzidek, pbrezina, plautrba, pmoore, preichl, rharwood, sbose, ssorce, vmojzis | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2017-08-08 19:11:20 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Fujisan
2016-11-09 08:25:04 UTC
Can you please attach the full logs? It's not clear to me which request returns the system error. Although I see the selinux child failed here, the return value from the selinux operation seems to return 0: (Wed Nov 9 09:09:13 2016) [sssd[be[opera]]] [dp_req_done] (0x0400): DP Request [PAM SELinux #321]: Request handler finished [0]: Success IIRC there should be selinux_child.log. I suspect some issues with libsemanage. I already saw such report on IRC but user did not reply anymore :-( So we could not fix it. Created attachment 1218862 [details]
/var/log/secure
Created attachment 1218864 [details]
/var/log/sssd/sssd_opera.log
SElinux is disabled on that client as well as on the other clients. Created attachment 1218885 [details]
/var/log/sssd/selinux_child.log
Petr, Could you look into selinux_child.log The following error from libsemanage is suspicious to me "Unable to read BackupPC module lang ext file." I wonder if this is a bug or a feature. If the IPA server wants us to set a SELinux context but SELinux is disabled how should SSSD handle this? Maybe it would be more consistent to say that if you want to disable SELinux on an IPA client you have to disable SSSD's SELinux provider as well? What do you mean by "disable SSSD's SELinux provider"? how would I do that? If SELinux is disabled, SSSD should detect and refrain from using it at runtime automatically. (In reply to Simo Sorce from comment #10) > If SELinux is disabled, SSSD should detect and refrain from using it at > runtime automatically. That's not a solution it's a workaround and there are more possible workarounds. It would be much better to fix root of cause and probably prevent such situations either in selinux_child or libsemanage I do not understand what you mean by definiying it a workaround ? If SELinux is disabled, then SSSD should not perform operations related to SELinux, this is not a workaround but a statement of the expected behavior SSSD should have. It can be easily done by a call to is_selinux_enabled() and then managed at runtime. (In reply to Simo Sorce from comment #12) > I do not understand what you mean by definiying it a workaround ? > > If SELinux is disabled, then SSSD should not perform operations related to > SELinux, this is not a workaround but a statement of the expected behavior > SSSD should have. > > It can be easily done by a call to is_selinux_enabled() and then managed at > runtime. I would recommend you to read description of this bug more carefully. There is written: 'I do not have this problem with my other ipa clients.' So if there is not any problem with selinux_child on other clients then recommendation to switch SELinux into disabled mode is just a workaround and not a solution. It will just hide symptoms on one machine. It will not solve a bug in selinux_child/libsemanage. (In reply to Lukas Slebodnik from comment #7) > Petr, > Could you look into selinux_child.log > The following error from libsemanage is suspicious to me > "Unable to read BackupPC module lang ext file." It looks like that SELinux module store is somehow corrupted. There's a probably /var/lib/selinux/active/modules/*/BackupPC directory with empty /var/lib/selinux/active/modules/*/BackupPC/lang_ext file. I don't know what is expected function of BackupPC module. The directory can be either remove completely removed; or you can try to fix lang_ext file using a file with the same name from different module. OK, I had this: # ll /var/lib/selinux/targeted/active/modules/400/ drwx------ 2 root root 4096 Jun 6 14:55 BackupPC drwx------ 2 root root 4096 Jun 6 14:55 docker # ll /var/lib/selinux/targeted/active/modules/400/BackupPC -rw-r--r-- 1 root root 0 Jun 6 14:55 cil -rw-r--r-- 1 root root 0 Jun 6 14:55 hll -rw-r--r-- 1 root root 0 Jun 6 14:55 lang_ext Here files are empty. So I removed both directories, BackupPC and docker. an then logged in as smith successfully this time on that ipa client and got this log (in /var/log/sssd/selinux_child.log) (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28963]]]] [pack_buffer] (0x0400): result [0] (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28963]]]] [main] (0x0400): selinux_child completed successfully (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [main] (0x0400): selinux_child started. (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [main] (0x0400): context initialized (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [main] (0x0400): performing selinux operations (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [get_seuser] (0x0040): SELinux user for smith: unconfined_u (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [get_seuser] (0x0040): SELinux range for smith: s0-s0:c0.c1023 (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [pack_buffer] (0x0400): result [0] (Wed Nov 9 17:02:00 2016) [[sssd[selinux_child[28977]]]] [main] (0x0400): selinux_child completed successfully On another ipa client where I always could log in successfully, I had non-empty files in /var/lib/selinux/targeted/active/modules/400/BackupPC. So, thank you, Petr. Your solution solved the problem. (In reply to Simo Sorce from comment #12) > I do not understand what you mean by definiying it a workaround ? > > If SELinux is disabled, then SSSD should not perform operations related to > SELinux, this is not a workaround but a statement of the expected behavior > SSSD should have. > > It can be easily done by a call to is_selinux_enabled() and then managed at > runtime. btw this would have positive performance impact. Calling the semanage functions does not come for free (IIRC semanage recursively copies a directory structure it uses iternally) and even though we try to detect if calling semanage is needed at all (by comparing known and new SELinux context), I think not running the code at all would further improve performance in case SELinux is not needed anyway. sssd does not directly touch anything in /var/lib/selinux/*. We could not truncate them. We use libsemanage in sssd. I think that empty file should be either ignored or better message should be logged then "Unable to read BackupPC module lang ext file." Assigning to libsemanage; feel free to close if there is nothing to improve in libsemanage. So the question is who, when and why created/imported BackupPC module. Do you know where it comes from? It's not a part of selinux-policy. It could be originated in some 3rd party package? libsemanage uses sandbox tmp directory where it works with modules and if everything is ok, it moves it to active. Users are not supposed to manipulates files directly in /var/lib/selinux. I have to say that after I removed directory /var/lib/selinux/targeted/active/modules/400/BackupPC, I tried to log in as smith on that ipa client and got the same error message with directory /var/lib/selinux/targeted/active/modules/400/docker "Unable to read docker module lang ext file.". So I removed it as well and then I could log in successfully. So it is not a BackupPC specific problem. (In reply to Petr Lautrbach from comment #18) > So the question is who, when and why created/imported BackupPC module. Do > you know where it comes from? It's not a part of selinux-policy. It could be > originated in some 3rd party package? Probably from: $ dnf info backuppc Last metadata expiration check: 0:19:48 ago on Wed Nov 9 21:34:25 2016. Available Packages Name : BackupPC Arch : x86_64 Epoch : 0 Version : 3.3.1 Release : 6.fc24 Size : 416 k Repo : updates Summary : High-performance backup system URL : http://backuppc.sourceforge.net/ License : GPLv2+ Description : BackupPC is a high-performance, enterprise-grade system for backing up Linux : and WinXX and Mac OS X PCs and laptops to a server's disk. BackupPC is highly : configurable and easy to install and maintain. This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |