Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,012
    • Issues 1,012
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 21
    • Merge requests 21
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #17112
Closed
Open
Issue created Oct 02, 2019 by intrigeri@intrigeriMaintainer

Persistence config files "insecure" backup get emptied in some situations

Originally created by @intrigeri on #17112 (Redmine)

As we can see on #10976 (comment 64669) and #10976 (comment 64649), if the permissions/ownership of the root directory of the persistent filesystem are wrong, live-additional-software.conf.insecure_disabled ends up being empty, which is unfortunate as it’s meant to be a backup that the user can later restore by hand.

I believe that’s because every call to disable_and_create_empty_persistence_conf_file in live-persist will rename the current live-additional-software.conf to live-additional-software.conf.insecure_disabled. So if the user immediately fixes the problem, the first time it happens, then we’re good. But if they reboot and unlock their persistence again, the (non-empty) backup gets overwritten by live-persist which replaces it with the new, empty config file it created during last boot.

Solution: ensure disable_and_create_empty_persistence_conf_file does not replace a non-empty .insecure_disabled backup file with an empty one.

Priority >> normal because it makes it harder to recover from the already painful #10976 (closed).

Note: I don’t understand why, in Cody’s report, the same problem did not happen for persistence.conf. There might be another problem on top of this one. But this should not block it from fixing the problem I’ve already understood here :)

Feature Branch: bugfix/17112-dont-empty-persistence-config-backup

Related issues

  • Related to #10976 (closed)
  • Related to #17116 (closed)
Edited May 15, 2020 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking