BALLESTEROS
Bit poster
Environment:
- Parallels Desktop 27.0.0 (build 58628), Standard edition
- Host: Apple Silicon Mac (M1)
- Guest: Fedora Linux 44 "Cosmic Spin" (aarch64)
- Kernel: 7.1.10-200.fc44.aarch64
- SELinux: Enforcing, selinux-policy-targeted-44.7-1.fc44
- 4 vCPU, ~6GB RAM allocated
- Parallels Tools version: 27.0.0-58628
Note: only tested on the Cosmic Spin. Not tested on the Fedora 44 KDE Plasma spin, so I have no data on whether it's affected too.
Symptom:
Running "Reinstall Parallels Tools" from the Parallels menu reports "Parallels Guest Tools were upgraded successfully!" in /var/log/parallels-tools-install.log, but two things are silently broken every time, reproduced across 8+ consecutive reinstall attempts:
1) SELinux CIL policy compile failure, logged every single run:
Compiling targeted prltimesync module
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/prltimesync/cil:35
semodule: Failed!
Compiling targeted prltoolsd module
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/prltoolsd/cil:51
semodule: Failed!
This looks like the bundled CIL policy for prltimesync/prltoolsd references a type or attribute that doesn't exist in the current Fedora 44 targeted policy (selinux-policy-targeted-44.7-1.fc44) - a version mismatch between the Parallels-bundled policy and the current Fedora policy.
2) Consequences observed from this:
After a full VM shutdown/restart, prltoolsd.service sometimes fails to start entirely:
audit: AVC avc: denied { execute } for pid=... comm="(prltoolsd.sh)" name="prltoolsd.sh" dev="sda3" scontext=system_u:system_r:init_t:s0 tcontext=system_u
bject_r:initrc_tmp_t:s0 tclass=file permissive=0
setroubleshoot correctly identifies the fix: the file's SELinux label should be lib_t but is initrc_tmp_t. Running "restorecon -Rv /usr/lib/parallels-tools/" and restarting the service resolves it manually.
The symlinks /usr/bin/prlcp, /usr/bin/prldnd, /usr/bin/prlcc (clipboard and drag-and-drop) are sometimes not created at all by the installer, even though the actual binaries exist under /usr/lib/parallels-tools/tools/tools-arm64/bin/. This breaks shared clipboard between host and guest until the symlinks are created manually.
What I ruled out:
Not a DKMS issue: installed dkms manually, no change - /var/lib/dkms/ stays empty, no build ever attempted for prl_fs/prl_tg, which appears to be expected/benign on this Tools version (shared folders now use FUSE via prl_fsd, and ToolGate appears to use standard virtio-vsock - /dev/vsock and vsock/vmw_vsock_virtio_transport kernel modules present and loaded).
Checked for duplicates first: searched kb.parallels.com and forum.parallels.com for "typeattributeset", "prltoolsd.sh" + "denied execute", and the missing-symlinks symptom - found nothing matching. The generic "Failed to resolve typeattributeset statement" CIL error is a known class of issue elsewhere (e.g. Red Hat KB 6979389, 5970311) but not previously reported for Parallels' own prltimesync/prltoolsd modules specifically.
Question: Is this a known SELinux policy version mismatch for Fedora 44 that will be fixed in an upcoming Tools update? Happy to provide the full /var/log/parallels-tools-install.log if useful.
- Parallels Desktop 27.0.0 (build 58628), Standard edition
- Host: Apple Silicon Mac (M1)
- Guest: Fedora Linux 44 "Cosmic Spin" (aarch64)
- Kernel: 7.1.10-200.fc44.aarch64
- SELinux: Enforcing, selinux-policy-targeted-44.7-1.fc44
- 4 vCPU, ~6GB RAM allocated
- Parallels Tools version: 27.0.0-58628
Note: only tested on the Cosmic Spin. Not tested on the Fedora 44 KDE Plasma spin, so I have no data on whether it's affected too.
Symptom:
Running "Reinstall Parallels Tools" from the Parallels menu reports "Parallels Guest Tools were upgraded successfully!" in /var/log/parallels-tools-install.log, but two things are silently broken every time, reproduced across 8+ consecutive reinstall attempts:
1) SELinux CIL policy compile failure, logged every single run:
Compiling targeted prltimesync module
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/prltimesync/cil:35
semodule: Failed!
Compiling targeted prltoolsd module
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/prltoolsd/cil:51
semodule: Failed!
This looks like the bundled CIL policy for prltimesync/prltoolsd references a type or attribute that doesn't exist in the current Fedora 44 targeted policy (selinux-policy-targeted-44.7-1.fc44) - a version mismatch between the Parallels-bundled policy and the current Fedora policy.
2) Consequences observed from this:
After a full VM shutdown/restart, prltoolsd.service sometimes fails to start entirely:
audit: AVC avc: denied { execute } for pid=... comm="(prltoolsd.sh)" name="prltoolsd.sh" dev="sda3" scontext=system_u:system_r:init_t:s0 tcontext=system_u
bject_r:initrc_tmp_t:s0 tclass=file permissive=0setroubleshoot correctly identifies the fix: the file's SELinux label should be lib_t but is initrc_tmp_t. Running "restorecon -Rv /usr/lib/parallels-tools/" and restarting the service resolves it manually.
The symlinks /usr/bin/prlcp, /usr/bin/prldnd, /usr/bin/prlcc (clipboard and drag-and-drop) are sometimes not created at all by the installer, even though the actual binaries exist under /usr/lib/parallels-tools/tools/tools-arm64/bin/. This breaks shared clipboard between host and guest until the symlinks are created manually.
What I ruled out:
Not a DKMS issue: installed dkms manually, no change - /var/lib/dkms/ stays empty, no build ever attempted for prl_fs/prl_tg, which appears to be expected/benign on this Tools version (shared folders now use FUSE via prl_fsd, and ToolGate appears to use standard virtio-vsock - /dev/vsock and vsock/vmw_vsock_virtio_transport kernel modules present and loaded).
Checked for duplicates first: searched kb.parallels.com and forum.parallels.com for "typeattributeset", "prltoolsd.sh" + "denied execute", and the missing-symlinks symptom - found nothing matching. The generic "Failed to resolve typeattributeset statement" CIL error is a known class of issue elsewhere (e.g. Red Hat KB 6979389, 5970311) but not previously reported for Parallels' own prltimesync/prltoolsd modules specifically.
Question: Is this a known SELinux policy version mismatch for Fedora 44 that will be fixed in an upcoming Tools update? Happy to provide the full /var/log/parallels-tools-install.log if useful.