Bug 1471544 - "SELinux is preventing systemd-journald from search access on the directory root" -- which directory is "root"?
"SELinux is preventing systemd-journald from search access on the directory r...
Status: NEW
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-07-16 15:47 EDT by Andrew Toskin
Modified: 2017-07-16 15:47 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Toskin 2017-07-16 15:47:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.