This bug appears to be happening again in Fedora 19. I updated from Fedora 17, and lost access to my home directory via samba. There was no logging in audit.log or in /var/log/messages related to the selinux denial of the samba home directory read. +++ This bug was initially created as a clone of Bug #558622 +++ Description of problem: ..idea, when actual boolean is 0 and one has folders samba-shared from within home dir then failure is silent. Sure we all should read man pages but reports into the syslog would put many minds at ease. that would nicely appear in syslog just next to samba error, and everything is clear :) thanks Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Daniel Walsh on 2010-01-25 15:29:05 EST --- Not sure what you are getting at. Please show me what you would have wanted the /var/log/messages entry to look like? --- Additional comment from lejeczek on 2010-01-30 16:57:14 EST --- selinux silently denies samba access to public_content_rw_t(maybe samba_share_t too) labelled shares in a user's home dir if samba_enable_home_dirs is 0 man page explains it but if this denial when happens could as well go into logs, for those who have missed samba_selinux, troubleshooting it would be quicker, I think --- Additional comment from Daniel Walsh on 2010-02-01 13:32:26 EST --- I agree, Miroslav change userdom_dontaudit_search_user_home_dirs(smbd_t) to userdom_search_user_home_content(smbd_t) This will allow samba to search through the user homedir but not list them. I don't think this is much less secure. --- Additional comment from Miroslav Grepl on 2010-02-01 14:43:39 EST --- Changed in selinux-policy-3.6.32-80.fc12 --- Additional comment from Fedora Update System on 2010-02-03 18:18:31 EST --- selinux-policy-3.6.32-82.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-82.fc12 --- Additional comment from Fedora Update System on 2010-02-04 20:42:58 EST --- selinux-policy-3.6.32-84.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1492 --- Additional comment from Fedora Update System on 2010-02-11 09:35:39 EST --- selinux-policy-3.6.32-84.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
We have allow smbd_t user_home_type : dir { getattr search open } ; Is auditd running correctly? systemctl status auditd
I see #!!!! This avc can be allowed using one of the these booleans: # samba_export_all_ro, samba_enable_home_dirs, samba_export_all_rw allow smbd_t user_home_t:file { read open };
(In reply to Miroslav Grepl from comment #1) > Is auditd running correctly? > > systemctl status auditd Yes, it is running: # systemctl status auditd auditd.service - Security Auditing Service Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled) Active: active (running) since Thu 2013-08-01 13:24:17 EDT; 22h ago Main PID: 736 (auditd) CGroup: name=systemd:/system/auditd.service ├─736 /sbin/auditd -n ├─743 /sbin/audispd └─744 /usr/sbin/sedispatch And I do see other (unrelated) messages in audit log, for example: type=USER_LOGIN msg=audit(1375458180.055:5289): pid=7886 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=192.168.1.4 terminal=ssh res=failed' I just tried it again to verify the issue, and can confirm that nothing is audited. I also can confirm there was no message in message.log about the audit queue being full or anything like that.
I restarted the auditd daemon (which systemctl couldn't do for some reason, but that's another issue) and tried again -- still no logging: auditd.service - Security Auditing Service Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled) Active: active (running) since Fri 2013-08-02 13:00:21 EDT; 4min 5s ago Process: 11399 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS) Main PID: 11398 (auditd) CGroup: name=systemd:/system/auditd.service ├─11398 /sbin/auditd -n ├─11403 /sbin/audispd └─11404 /usr/sbin/sedispatch Aug 02 13:00:21 edison systemd[1]: Started Security Auditing Service. Aug 02 13:00:21 edison auditd[11398]: Started dispatcher: /sbin/audispd pid: 11403 Aug 02 13:00:21 edison audispd[11403]: priority_boost_parser called with: 4 Aug 02 13:00:21 edison audispd[11403]: max_restarts_parser called with: 10 Aug 02 13:00:21 edison audispd[11403]: audispd initialized with q_depth=120 and 1 active plugins Aug 02 13:00:21 edison auditd[11398]: Init complete, auditd 2.3.1 listening for events (startup state enable)
Try to run # semodule -B re-test # ausearch -m avc -ts recent
Nope: [root@edison ~]# setsebool -P samba_enable_home_dirs off [root@edison ~]# semodule -B [root@edison ~]# ausearch -m avc -ts recent <no matches> I tested here by attempting to access the Samba home directory share... Windows gave me an "Access is denied." error. Now back to Fedora: [root@edison ~]# ausearch -m avc -ts recent <no matches>
Also confirmed via smbclient (to take Windows out of the equation, not that that should matter): raman@edison ~ $ smbclient //edison/raman Enter raman's password: Domain=[HOMENET] OS=[Unix] Server=[Samba 4.0.7] smb: \> ls NT_STATUS_ACCESS_DENIED listing \* smb: \>
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.