Bug 1471544
| Summary: | SELinux Troubleshooter reports should use absolute paths | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Audrey Yeena Toskin <audrey> |
| Component: | setroubleshoot | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | dominick.grift, dwalsh, lvrabec, mgrepl, plautrba, pmoore, ssekidde, vmojzis |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-06 16:26:37 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: | |
| Embargoed: | |||
So to summarize, SELinux Troubleshooter should use the full absolute path in its reports and suggested `restorecon` commands. *** Bug 1471540 has been marked as a duplicate of this bug. *** Sadly the kernel does not give us the full path in a lot of situations. So setroubleshoot can only devine so much. you can turn the kernel auditing up to record full paths but there is a heavy performance penalty. |
After making a fresh installation of Fedora 26 Workstation x86_64, I started to restore local file backups, including my entire home directory, virtual machines from /var/lib/libvirt/, /root/.bashrc, and a few things in /etc/, using rsync. During this operation, I hit *a lot* of SE Linux alerts, including this one, plus others that have already recently been reported. SETroubleshoot reports "SELinux is preventing /usr/lib/systemd/systemd-journald from search access on the directory root... root default label should be syslogd_var_run_t." It recommends running /sbin/restorecon -v root But there is/was no `root/` in my current working directory or home directory. I was restoring backups *from* a directory called root on another hard drive, which matches the filesystem hierarchy of /, so that I can rsync the files and folders I mentioned above in one go, like this: rsync \ # Preserve file owner, timestamp, permissions, sparseness --archive --sparse --executability --acls --xattrs \ # Display and save transfer progress --partial --info=name,progress2 --log-file="$log_file" \ # Source and destination: $backup_device/root/ / If "root" refers to that directory, then the recommended restorecon command should have specified the full path. Also, when I tried restorecon on the backup directory, it just says "Warning no default label for $backup_device/root/". If "root" means either / or /root/, then I'm also not sure how the context of either of those directories could have gotten messed up, since rsync has no options to preserve the SELinux file context, so it's not like I was duplicating incorrect contexts from my backups, and I only copied one file in /root/ anyway.