This pull request enhances the safety of the `linux_wipe.sh` script by
ensuring that destructive file operations do not affect network-mounted
filesystems. The changes introduce checks to detect network filesystems,
prevent accidental deletion of remote data, and improve the reliability
of wipe operations by avoiding crossing filesystem boundaries.
**Network filesystem safety improvements:**
* Added a `NETWORK_FS_TYPES` variable and functions to detect and
unmount network filesystems, preventing the script from deleting data on
NFS, CIFS, SMB, SSHFS, and similar mounts.
(`ee/server/service/embedded_scripts/linux_wipe.sh`)
[[1]](diffhunk://#diff-7ac85220cbd45e63481837a405dacf198822a4fbf885b88f89b9bc870c947fccR3-R4)
[[2]](diffhunk://#diff-7ac85220cbd45e63481837a405dacf198822a4fbf885b88f89b9bc870c947fccR17-R84)
* Introduced an `unmount_network_filesystems` function called before
wiping operations to unmount all detected network filesystems.
(`ee/server/service/embedded_scripts/linux_wipe.sh`)
* Added an `is_network_mount` function to skip wiping any path residing
on a network filesystem.
(`ee/server/service/embedded_scripts/linux_wipe.sh`)
**Safe file deletion enhancements:**
* Implemented a `safe_rm` function that ensures file deletions do not
cross filesystem boundaries, using `rm --one-file-system` or `find
-xdev` as a fallback. All destructive operations now use this wrapper.
(`ee/server/service/embedded_scripts/linux_wipe.sh`)
* Updated `wipe_non_essential_data` and `wipe_system_files` to use
`safe_rm` and to skip paths on network filesystems.
(`ee/server/service/embedded_scripts/linux_wipe.sh`)
These changes significantly reduce the risk of deleting data on remote
or shared filesystems during a wipe operation.
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves #
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [ ] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files)
for more information.
- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects
- [ ] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [ ] Added/updated automated tests
- [ ] Where appropriate, [automated tests simulate multiple hosts and
test for host
isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing)
(updates to one hosts's records do not affect another)
- [ ] QA'd all new/changed functionality manually
For unreleased bug fixes in a release candidate, one of:
- [ ] Confirmed that the fix is not expected to adversely impact load
test results
- [ ] Alerted the release DRI if additional load testing is needed
## Database migrations
- [ ] Checked schema for all modified table for columns that will
auto-update timestamps during migration.
- [ ] Confirmed that updating the timestamps is acceptable, and will not
cause unwanted side effects.
- [ ] Ensured the correct collation is explicitly set for character
columns (`COLLATE utf8mb4_unicode_ci`).
## New Fleet configuration settings
- [ ] Setting(s) is/are explicitly excluded from GitOps
If you didn't check the box above, follow this checklist for
GitOps-enabled settings:
- [ ] Verified that the setting is exported via `fleetctl
generate-gitops`
- [ ] Verified the setting is documented in a separate PR to [the GitOps
documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485)
- [ ] Verified that the setting is cleared on the server if it is not
supplied in a YAML file (or that it is documented as being optional)
- [ ] Verified that any relevant UI is disabled when GitOps mode is
enabled
## fleetd/orbit/Fleet Desktop
- [ ] Verified compatibility with the latest released version of Fleet
(see [Must
rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md))
- [ ] If the change applies to only one platform, confirmed that
`runtime.GOOS` is used as needed to isolate changes
- [ ] Verified that fleetd runs on macOS, Linux and Windows
- [ ] Verified auto-update works from the released version of component
to the new version (see [tools/tuf/test](../tools/tuf/test/README.md))
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#33381 unreleased Linux unlock bug.
# Checklist for submitter
## Testing
- [x] QA'd all new/changed functionality manually
Fixes#31291
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
See [Changes
files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files)
for more information.
## Testing
- [x] QA'd all new/changed functionality manually
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- New Features
- Linux lock now switches Ubuntu + GDM systems to text mode to avoid GUI
issues.
- Persistent lock message is shown and survives reboots.
- Unlock restores the original GUI mode automatically when applicable.
- Bug Fixes
- Prevents black-screen behavior on Ubuntu + GDM after locking by
rebooting to text mode.
- Ensures lock message consistently appears across sessions.
- Improves reliability of session handling during lock/unlock.
- Chores
- Added change note describing the updated Linux lock behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
#22437
There is a bug in Ubuntu 24.04's distribution of GDM that prevents it
from starting correctly and displaying a prompt to the user if
`/etc/nologin` is present. This issue is not present on the current
release of Fedora, meaning it is Ubuntu specific.
The way we lock users out is by manually creating the `nologin` file and
then masking the `systemd-user-sessions` systemd unit, which creates the
file on shutdown and deletes it on startup. This will cause a PAM policy
to fail and prevents anyone from logging in. When we unlock the system
we delete the `nologin` file, unmask the `systemd-user-sessions` unit,
and manually run the binary that it should start.
This process removes the cause of the GDM bug, but we need to reboot the
machine to get GDM working again.
While I have not yet been able to determine the exact cause of the bug,
this fix will prevent the user from being stuck with a black screen once
the machine is unlocked.
This fix will not remedy GDM showing a black screen upon being locked,
it only ensures that the user isn't stuck having to manually reboot the
machine once it's unlocked.
We should check back on this soon to see if the bug gets been fixed
upstream.
#20370
Part 2 to #20699. Apparently `systemd` now automatically deletes
`/etc/nologin` on startup. In the previous PR, rebooting the machine
would remove the nologin file and allow users to login. This PR masks
the service that performs the deletion, preventing it from running.
The message displayed to the user will be what is specified in [this
file](7767896d12/tmpfiles.d/systemd-nologin.conf (L10)).
It's not the best, but I suspect messing with too many systemd files
could come back to bite us in the future if things change, so I'll leave
it as-is.
As part of this PR #20224, I added the new script to one location but
didn't notice that it wasn't included in the embedded scripts directory.
This also adds an unlock script that will reset the registry values to
their original settings
#18173
Creates a detached child shell process to wipe the host. This lets the
main shell script return and tells the server the command has completed,
clearing it from the run queue.
Now shuts the host down after being wiped instead of leaving it running
without files like a zombie
