Project

General

Profile

Bug #7216

Instructions to backup persistent data do not respect ownership of files

Added by sajolida about 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Persistence
Target version:
Start date:
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
doc/7216-persistence-backup-permissions
Type of work:
End-user documentation
Blueprint:
Starter:
No
Affected tool:

Description

The instructions to manually copy persistent data to a new device
override the ownership of files owned by amnesia:amnesia to root:root.
This leads to unusable personal files.

A workaround could be to issue the following command after copying the
folders:

find /live/persistence/TailsData_unlocked/ -maxdepth 1 -type d -uid
1000 -exec chown -R 1000:1000 '{}' \;

Shall we ask the user to execute this command, or shall we find a better
way of solving that issue?


Related issues

Related to Tails - Feature #5301: Clone or backup system for the persistent volume Confirmed 01/27/2015

Associated revisions

Revision f1f5912d (diff)
Added by Tails developers almost 5 years ago

Fix files ownership while copying persistence (Closes: #7216)

The previous instructions to copy the persistent data were creating personal
files that belong to root. I don't think there is a way of preserving the
original ownership using Nautilus (unless doing a "move" instead of a "copy" but
that's not what we are trying to do here).

History

#1 Updated by sajolida about 5 years ago

find /live/persistence/TailsData_unlocked/ -maxdepth 1 -type d -uid
1000 -exec chown -R 1000:1000 '{}' \;

Or something longer but more straight-forward:

chown -R amnesia:amnesia
/live/persistence/TailsData_unlocked/{bookmarks,claws-mail,gnome-keyrings,gnupg,openssh-client,Persistent}

#2 Updated by chouchou almost 5 years ago

I can confirm that bug, I did the 'chown -R' and it worked fine.
I think it would be great to , at least, add this command in the documentation (it's more understandable than the 'find' for users-not-used-to-command-line), but if there was another way to backup persistent data without writing things in a root-terminal, it would be better.

#3 Updated by sajolida almost 5 years ago

  • Assignee set to sajolida

#4 Updated by intrigeri almost 5 years ago

  • Starter set to No

IMO this ticket would be worth priority = Elevated.

#5 Updated by sajolida almost 5 years ago

  • Related to Feature #5301: Clone or backup system for the persistent volume added

#6 Updated by sajolida almost 5 years ago

  • Category set to Persistence
  • Assignee changed from sajolida to intrigeri
  • Priority changed from Normal to Elevated
  • Feature Branch set to doc/7216-persistence-backup-permissions

In the end I opted for the find version because it won't have to be adapted in the future if new folders appear in persistence.

I also reduced it a little bit to fit on one line. Here is my reasoning:

  • -type d doesn't matter, we can run chown -R on file as well, if any
  • -maxdepth 1 can also be removed, it would only make a difference in case of a weird combination of subfolders with different ownerships that I don't think would happen

Having those two options probably speeds up the process a lit bit, but let's say we don't care.

#7 Updated by sajolida almost 5 years ago

  • Target version set to Tails_1.1

Added target version 1.1 as the UEFI and syslinux migration might break quite a few sticks...

#8 Updated by intrigeri almost 5 years ago

  • Assignee changed from intrigeri to sajolida
  • QA Check set to Info Needed

I don't get how this command-line (with -uid 1000) can possibly fix ownership of files owned by root:root. Simply dropping -uid 1000 is not an option, as it would give ownership of directories that are rightfully owned by root:root (e.g. the apt one) to the desktop user.

#9 Updated by sajolida almost 5 years ago

  • Assignee changed from sajolida to intrigeri
  • QA Check changed from Info Needed to Ready for QA

I don't get how this command-line (with -uid 1000) can possibly fix
ownership of files owned by root:root. Simply dropping -uid 1000 is
not an option, as it would give ownership of directories that are
rightfully owned by root:root (e.g. the apt one) to the desktop
user.

The things is that those personal folders (Persistent, .gnupg, etc.) are
already created with the right permissions when the persistent volume is
created on the new device. Then the ownership of these folders is not
overwritten when the old folders are copying on top of them with the
"Merge All" option. Only the files inside those folders are attributed
to root:root.

The `find` command attributes to the amnesia:amnesia the files that are
in the folders that already belonged to amnesia:amnesia.

#10 Updated by intrigeri almost 5 years ago

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 0 to 100
  • QA Check changed from Ready for QA to Pass

#11 Updated by BitingBird almost 5 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF