-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
selinux: relabeling after Ignition breaks on absolute symlinks #512
Comments
@abitzer thanks for the report. Which platform/install-method is this on? If not too big, would you be able to attach the Ignition config as well (redacting any secret first)? |
ignition-files.service
failing on setfiles
The fact that the boot continued even though Ignition failed should be fixed by coreos/ignition-dracut#188, which will be in the next The underlying issue is that |
I did some more testing and it seems to boil down to:
The adapted ignition file can be found here. I use Qemu on Windows. |
I'm able to reproduce this with your config.
The relevant bit in there is:
but earlier in the Ignition logs on the scrollback of my console I do see:
It seems that
So it looks like it doesn't like the symlink being an absolute path. I'd think this wouldn't be a problem because we pass You can workaround this issue by using a relative path ( |
This is reproducible even outside of Ignition/initramfs context. Additionally, it fails even if we are already passing the
Reported upstream at SELinuxProject/selinux#248. |
ignition-files.service
failing on setfiles
Thanks for the great support. |
Correct. @jlebon mentioned it would be fixed in the next set of releases (should be out today or tomorrow). The probably is a change in how systemd upstream worked and we just now discovered it. |
Also, I would like to thank you @abitzer for running |
Upstream patch: https://lore.kernel.org/selinux/20200604200831.28866-1-stephen.smalley.work@gmail.com/T/#u. I've verified that it fixes the bug. I've also submitted a patch to clarify documentation around symlink handling: https://lore.kernel.org/selinux/20200604191240.263819-1-jlebon@redhat.com/T/#u. Finally, discussing this made me realize that we shouldn't be using |
One thing that confused me when investigating SELinuxProject#248 (i.e. coreos/fedora-coreos-tracker#512) was that the manual page for `setfiles` seemed to imply that paths were fully resolved. This was consistent with the issues above where `setfiles` was failing because the target of the symbolic link didn't exist. But in fact, the wording around symbolic links in `setfiles`/`restorecon` refers actually to whether the parent directories are canonicalized via `realpath(3)` before labeling. Clarify the man pages to explain this.
One thing that confused me when investigating #248 (i.e. coreos/fedora-coreos-tracker#512) was that the manual page for `setfiles` seemed to imply that paths were fully resolved. This was consistent with the issues above where `setfiles` was failing because the target of the symbolic link didn't exist. But in fact, the wording around symbolic links in `setfiles`/`restorecon` refers actually to whether the parent directories are canonicalized via `realpath(3)` before labeling. Clarify the man pages to explain this. Signed-off-by: Jonathan Lebon <jlebon@redhat.com> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
One thing that confused me when investigating SELinuxProject/selinux#248 (i.e. coreos/fedora-coreos-tracker#512) was that the manual page for `setfiles` seemed to imply that paths were fully resolved. This was consistent with the issues above where `setfiles` was failing because the target of the symbolic link didn't exist. But in fact, the wording around symbolic links in `setfiles`/`restorecon` refers actually to whether the parent directories are canonicalized via `realpath(3)` before labeling. Clarify the man pages to explain this. Signed-off-by: Jonathan Lebon <jlebon@redhat.com> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
The coreos.ignition.symlink test was added to test setting absolute symlinks that was recently broken. The fix hasn't landed on this branch yet so we'll deny it for now. - coreos/fedora-coreos-tracker#512 - coreos/coreos-assembler#1641
The coreos.ignition.symlink test was added to test setting absolute symlinks that was recently broken. The fix hasn't landed on this branch yet so we'll deny it for now. - coreos/fedora-coreos-tracker#512 - coreos/coreos-assembler#1641
The coreos.ignition.symlink test was added to test setting absolute symlinks that was recently broken. The fix hasn't landed on this branch yet so we'll deny it for now. - coreos/fedora-coreos-tracker#512 - coreos/coreos-assembler#1641
The coreos.ignition.symlink test was added to test setting absolute symlinks that was recently broken. The fix hasn't landed on this branch yet so we'll deny it for now. - coreos/fedora-coreos-tracker#512 - coreos/coreos-assembler#1641
The fix for this went into testing stream release |
The fix for this went into stable stream release |
One thing that confused me when investigating SELinuxProject/selinux#248 (i.e. coreos/fedora-coreos-tracker#512) was that the manual page for `setfiles` seemed to imply that paths were fully resolved. This was consistent with the issues above where `setfiles` was failing because the target of the symbolic link didn't exist. But in fact, the wording around symbolic links in `setfiles`/`restorecon` refers actually to whether the parent directories are canonicalized via `realpath(3)` before labeling. Clarify the man pages to explain this. Signed-off-by: Jonathan Lebon <jlebon@redhat.com> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
on:
But workings on:
The text was updated successfully, but these errors were encountered: