Skip to content
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

fix-cat2.yml re-writes /etc/fstab line for /boot/efi with a device path instead of VFAT Serial Number (psuedo-UUID) replace #222

Closed
BJSmithIEEE opened this issue Sep 14, 2023 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@BJSmithIEEE
Copy link

BJSmithIEEE commented Sep 14, 2023

Describe the Issue
When the fix-cat2.yml task re-writes the /etc/fstab line for required DISA STIG /boot/efi options (e.g., noexec, nosuid,etc...), it re-writes it with a device path (e.g., /dev/sdX1) from the value capture in {{ boot_efi_mount.device }}.

Expected Behavior
Preserve VFAT Serial Number (UUID=XXXX-XXXX) and re-write this instead. It's a psuedo-UUID because it's unlike all other Linux 128-bit (32 hex) UUIDs used for GPT, UUID, DM-LVM2, etc... This is because it's a 32-bit (8 hex) timestamp value when the VFAT file system is created.

Actual Behavior
We're still tracking down the root cause, but it seems when the values are captured in the prior JSON, possibly due to the Ansible Galaxy POSIX module's Mount or other functions, it expects a 128-bit (32 hex) UUID, instead of a 32-bit (8 hex) Serial Number, and skips, falling back to the Device path. The EFI System Partition (ESP) mounted as /boot/efi is a FAT file system, and does not have a traditional 128-bit (32 hex) UUID, but the Linux mount command will take a 32-bit (8 hex) Serial Number as equivalent. It looks like if the UUID is not captured, the Device is used, hence the problem.

Control(s) Affected
rhel_08_010572

Environment (please complete the following information):

  • Ansible Version: 2.14 (RHEL8.8 Ansible-core with Ansible Galaxy modules)
  • Host Python Version: 3.6.8 (RHEL8.8 Python3)
  • Ansible Server Python Version: n/a
  • Additional Details: RHEL8.8 installation with the US CyberX.mil DISA STIG Ansible Playbooks run, using Ansible Lockdown to further lockdown

Additional Notes
We never noticed it until we were using a Dell PowerEdge 740xd that has a tendency to 'flip' our 240GB RAID volume for our system drive to /dev/sdb, and our multi-TB RAID volume for our data drive to /dev/sda. We confirmed Anaconda installed the OS to /dev/sda and created the UUID=XXXX-XXXX entry proper for /boot/efi, but it was changed after running Ansible-Lockdown for RHEL8-STIG. We will attempt to reproduce it on another system.

Possible Solution
Ensure VFAT 32-bit Serial Number is captured and re-written for /boot/efi in /etc/fstab when modifying options, and do not change to the device path, which may be enumerated differently on subsequent boots.

@BJSmithIEEE BJSmithIEEE added the bug Something isn't working label Sep 14, 2023
@uk-bolly
Copy link
Member

hi @BJSmithIEEE

Thank you for taking the time to raise this issue also for the great explanation and information provided really helps us to get a good solution.
I will aim to work on this (clients permitting the next couple of days).

kindest regards

uk-bolly

@uk-bolly uk-bolly self-assigned this Sep 19, 2023
uk-bolly added a commit that referenced this issue Sep 19, 2023
@uk-bolly
Copy link
Member

uk-bolly commented Apr 9, 2024

hi @BJSmithIEEE

I believe this issue has been addressed and merged?
I will close this, but feel free to reopen if you are still experiencing this problem.

many thanks

uk-bolly

@uk-bolly uk-bolly closed this as completed Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants