Bug #7216

Instructions to backup persistent data do not respect ownership of files

Added by sajolida 2014-05-11 10:25:16 . Updated 2014-07-22 22:51:51 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Persistence
Target version:
Tails_1.1
Start date:
Due date:
% Done:

100%

Feature Branch:
doc/7216-persistence-backup-permissions
Type of work:
End-user documentation
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

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?

Subtasks

Related issues

Related to Tails - Feature #5301: Backup system for the Persistence Confirmed 2015-01-27

History

#1 Updated by sajolida 2014-05-12 03:34:32

> 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 2014-06-05 04:19:58

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 2014-06-06 01:21:52

  • Assignee set to sajolida

#4 Updated by intrigeri 2014-06-21 15:15:51

  • Starter set to No

IMO this ticket would be worth priority = Elevated.

#5 Updated by sajolida 2014-06-27 19:48:47

  • related to Feature #5301: Backup system for the Persistence added

#6 Updated by sajolida 2014-06-27 20:00:22

  • 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 2014-06-27 20:01:16

  • 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 2014-06-28 09:05:05

  • 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 2014-06-29 11:25:40

  • 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 2014-06-30 08:18:16

  • 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 2014-07-22 22:51:51

  • Status changed from Fix committed to Resolved