systemd-cryptsetup-generator permission denied on boot
#1425
Comments
|
Cryptsetup was recently updated; however, I haven't seen your behavior. Please check the file context for systemd-cryptsetup.
That said, that is on the image and it would be unlikely that is the cause of the issue. Are you able to boot sucessfully with permissive mode enabled? |
➜ ~ ls -lZ /usr/bin/systemd-cryptsetup
-rwxr-xr-x. 4 root root system_u:object_r:bin_t:s0 95112 Jan 1 1970 /usr/bin/systemd-cryptsetup
I'm not sure, I don't know exactly how to enable that, but I'll track it down and give it a try. |
|
Attempting now to set |
|
It now boots successfully after the change just mentioned. I'll revert it now just to be sure. |
|
Yep, reverting it to |
|
With permissive enabled I get the following fstab related audit errors: Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.732:3): avc: denied { create } for pid=911 comm="systemd-fstab-g" name=".#50-device-timeout.conf97ed252054a39cd0" scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1
Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.732:4): avc: denied { read write open } for pid=911 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2df6961bfa\x2de1db\x2d424c\x2db69b\x2dd1f8d0a49583.device.d/.#50-device-timeout.conf97ed252054a39cd0" dev="tmpfs" ino=831 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1
Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.732:5): avc: denied { getattr } for pid=911 comm="systemd-fstab-g" path="/run/systemd/generator/dev-mapper-luks\x2df6961bfa\x2de1db\x2d424c\x2db69b\x2dd1f8d0a49583.device.d/.#50-device-timeout.conf97ed252054a39cd0" dev="tmpfs" ino=831 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1
Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.732:6): avc: denied { setattr } for pid=911 comm="systemd-fstab-g" name=".#50-device-timeout.conf97ed252054a39cd0" dev="tmpfs" ino=831 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1
Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.732:7): avc: denied { remove_name } for pid=911 comm="systemd-fstab-g" name=".#50-device-timeout.conf97ed252054a39cd0" dev="tmpfs" ino=831 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=dir permissive=1
Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.732:8): avc: denied { rename } for pid=911 comm="systemd-fstab-g" name=".#50-device-timeout.conf97ed252054a39cd0" dev="tmpfs" ino=831 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=file permissive=1
Jun 23 16:57:04 dredd kernel: audit: type=1400 audit(1719133023.735:9): avc: denied { remove_name } for pid=911 comm="systemd-fstab-g" name=".#50-device-timeout.conff7105f97f83a6f27" dev="tmpfs" ino=839 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 tclass=dir permissive=1the directory I believe it's accessing has the following labels: ➜ dev-mapper-luks\x2de28120fb\x2d3882\x2d41f3\x2dbc02\x2d35f61ce2ad78.device.d ls -lZ
total 8
-rw-r--r--. 1 root root system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 89 Jun 23 16:57 40-device-timeout.conf
-rw-r--r--. 1 root root system_u:object_r:systemd_cryptsetup_generator_unit_file_t:s0 146 Jun 23 16:57 50-device-timeout.conf |
|
After running the logs through the After applying it the system seems to be working well now. Guess now just to work out if this issue belongs at silverblue or elsewhere? |
|
Please post this on silverblues tracker. Both of those generators are from silverblue/fedora and it's odd that they required a new policy. |
|
So I do not have any dropin directories for my luks disk like you are showing. dev-mapper-luks-lux\x2.... should be generated from cryptsetup-generator. Where are those two dropin files being created? |
Describe the bug
When I boot my bluefin system and login I'm dropped into an environment without my home directory mounted.
Opening terminals and applications fail as
/home/timisn't present.What did you expect to happen?
/home/<user>to be present and everything to boot normally.Output of
rpm-ostree statusThe earlier pinned version was working correctly, no issues with mounting on boot.
Output of
groupsExtra information or context
systemd-cryptsetup-generatorfailing to runMay be unrelated, but a flow on kernel error:
The text was updated successfully, but these errors were encountered: