Project

General

Profile

Bug #15566

Feature #14568: Additional Software Packages

Bug #15567: Fix bugs and UX issues in the Additional Software beta

Additional Software on newly created partition are not shown in configuration window

Added by alant over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
Start date:
05/03/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Additional Software Packages

Description

The newly created persistence is not readeable by amnesia user, runnig the configuration window:

drwx------ 3 tails-persistence-setup root 60 May 3 11:11 /media/tails-persistence-setup/


Related issues

Blocked by Tails - Bug #15627: feature/14594-asp-gui FTBFS due to merge conflicts Resolved 05/29/2018

Associated revisions

Revision ab6dfff1 (diff)
Added by intrigeri over 1 year ago

Ensure the amnesia user can cross the /media/tails-persistence-setup/ directory boundary (refs: #15566)

A newly created persistent volume is mounted on
/media/tails-persistence-setup/TailsData by t-p-s (via udisks2). At the end of
the (new) persistent volume configuration process, we display a "gear" icon that
when clicked, starts tails-additional-software-config as the amnesia user.
tails-additional-software-config needs to read
/media/tails-persistence-setup/TailsData/live-additional-software.conf
(otherwise tails-additional-software-config pretends no ASP is configured yet).
Without these custom, relaxed permissions, that would be impossible: by default,
/media/tails-persistence-setup is created (presumably by udisks2) with
permissions 0700 and owned by tails-persistence-setup:root.

This change is safe because:

1. /media/tails-persistence-setup/TailsData is the only thing that ever gets
created under /media/tails-persistence-setup;
2. TailsData, i.e. the root of the persistent filesystem, is world-readable
so under normal circumstances, when Tails was started with the persistent
volume unlocked, the amnesia user would be allowed to access it anyway.

Still, this change does not seem to be enough to fix the UX problem we're after
here. For some reason tails-additional-software-config still pretends that no
ASP is configured yet, even though it does seem to have all the permissions it
needs to list them: see https://labs.riseup.net/code/issues/15566#note-7
for details.

Revision 2ced3c98 (diff)
Added by intrigeri over 1 year ago

Use numeric GID: we start systemd-tmpfiles-setup.service before live-config, which creates the amnesia group (refs #15566).

Revision 81749e2b (diff)
Added by intrigeri over 1 year ago

Give up on, and revert, the tmpfiles.d-based implementation of "Ensure the amnesia user can cross the /media/tails-persistence-setup/ directory boundary (refs: #15566)"

Even a numeric GID won't work when we run before the corresponding group has
is created.

This reverts commits ab6dfff13fb1a7e282337f379ad35f38f60b8063
and 2ced3c98b16343cd3a9bd7e67dc29f6e5fb5c245.

Revision f92d53d5 (diff)
Added by intrigeri over 1 year ago

Ensure the amnesia user can cross the /media/tails-persistence-setup/ directory boundary (refs: #15566)

… by creating that directory via a live-config hook, with appropriate
ownership and permissions.

A newly created persistent volume is mounted on
/media/tails-persistence-setup/TailsData by t-p-s (via udisks2). At the end of
the (new) persistent volume configuration process, we display a "gear" icon that
when clicked, starts tails-additional-software-config as the amnesia user.
tails-additional-software-config needs to read
/media/tails-persistence-setup/TailsData/live-additional-software.conf
(otherwise tails-additional-software-config pretends no ASP is configured yet).
Without these custom, relaxed permissions, that would be impossible: by default,
/media/tails-persistence-setup is created (presumably by udisks2) with
permissions 0700 and owned by tails-persistence-setup:root.

This change is safe because:

1. /media/tails-persistence-setup/TailsData is the only thing that ever gets
created under /media/tails-persistence-setup;
2. TailsData, i.e. the root of the persistent filesystem, is world-readable
so under normal circumstances, when Tails was started with the persistent
volume unlocked, the amnesia user would be allowed to access it anyway.

Still, this change does not seem to be enough to fix the UX problem we're after
here. For some reason tails-additional-software-config still pretends that no
ASP is configured yet, even though it does seem to have all the permissions it
needs to list them: see https://labs.riseup.net/code/issues/15566#note-7
for details.

Revision 9c782e05 (diff)
Added by alant about 1 year ago

ASP: allow opening persistence creation wizard from configuration window

Refs: #15566

Revision 57be3a55 (diff)
Added by alant about 1 year ago

ASP: search new persistence when updating configuration window

Refs: #15566

Revision 977fe880 (diff)
Added by alant about 1 year ago

ASP: watch for future persistence configuration file when no persistence exists

Refs: #15566

History

#1 Updated by alant over 1 year ago

  • Parent task changed from #14592 to #15567

#2 Updated by alant over 1 year ago

  • Tracker changed from Feature to Bug

#3 Updated by intrigeri over 1 year ago

  • Assignee set to alant
  • Target version set to Tails_3.8
  • QA Check set to Info Needed

If that's something you think is on my plate, please explain how to reproduce :)

#4 Updated by intrigeri over 1 year ago

  • Category set to Persistence
  • Assignee changed from alant to intrigeri
  • QA Check deleted (Info Needed)
  • Affected tool set to Additional Software Packages

I'll try to reproduce myself.

#6 Updated by intrigeri over 1 year ago

  • Blocked by Bug #15627: feature/14594-asp-gui FTBFS due to merge conflicts added

#7 Updated by intrigeri over 1 year ago

I think there are two things.

First, the permissions issue can be workarounded by running sudo install -o tails-persistence-setup -g amnesia -m 0710 -d /media/tails-persistence-setup before creating the persistent volume (via the notification triggered when installing a package). ACLs would be slightly nicer but it looks like our aufs+tmpfs stack does not support them. We could either ensure this directory exists via /usr/lib/tmpfiles.d/ or use chgrp and chmod in t-p-s:bin/tails-fix-persistent-volume-permissions. Regardless, as long as this directory exists before udisks mounts creates the mountpoint, then the amnesia user is allowed to reach the file the ASP config GUI needs to read (see below how I tested this).

But at the end of the persistence config process in t-p-s, when I click the "gear" icon for ASP, no package is listed. I don't know why but that seems to be a bug in the ASP Python code because permissions seem to be OK:

$ ls -l /media
drwx--x--- 3 tails-persistence-setup amnesia 60 Jun  6 07:43 tails-persistence-setup
$ cat /media/tails-persistence-setup/TailsData/live-additional-software.conf
cowsay
$ test -d /media/tails-persistence-setup/TailsData && echo found
found
$ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.isdir("/media/tails-persistence-setup/TailsData")
True

So I'll fix the permissions issue and will then reassign to Alan so he can fix the remaining problem, which seems to be outside of my realm.

#8 Updated by intrigeri over 1 year ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

intrigeri wrote:

So I'll fix the permissions issue

Done in commit ab6dfff13f. Will test before reassigning to Alan.

#9 Updated by intrigeri over 1 year ago

  • Assignee changed from intrigeri to alant
  • % Done changed from 10 to 20

On a build from f92d53d55e1f255756c6619b698674e1e821f141, once tps has created the persistent volume but before clicking the gear icon, I've done the same tests as in #15566#note-7 and got the same results => the amnesia user definitely has access to the file it needs to read. Then I've clicked the gear icon and the list of ASP is still empty. So I think I've fixed the only part of the bug that was vaguely related to t-p-s and the remaining issue is in the ASP config GUI code => reassigning to Alan.

#10 Updated by alant about 1 year ago

intrigeri wrote:

On a build from f92d53d55e1f255756c6619b698674e1e821f141, once tps has created the persistent volume but before clicking the gear icon, I've done the same tests as in #15566#note-7 and got the same results => the amnesia user definitely has access to the file it needs to read. *

Great thanks!

Then I've clicked the gear icon and the list of ASP is still empty. So I think I've fixed the only part of the bug that was vaguely related to t-p-s and the remaining issue is in the ASP config GUI code => reassigning to Alan.

I'll do the rest.

#11 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_3.8 to Tails_3.9

#12 Updated by alant about 1 year ago

  • % Done changed from 20 to 60
  • QA Check set to Ready for QA

#13 Updated by u about 1 year ago

Alan: if this is ready for QA, you should either assign it to intrigeri or segfault?

#14 Updated by u about 1 year ago

Or do you plan to review intrigeri's work here?

#15 Updated by alant about 1 year ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (alant)
  • % Done changed from 60 to 100
  • QA Check changed from Ready for QA to Pass

Tested OK in ISO built from e3327d7236fef3bba006a5cc8c55b49dfb77867b.

#16 Updated by u about 1 year ago

Alan: is this to be merged somewhere and if yes, when? Do you need help?

#17 Updated by alant about 1 year ago

u wrote:

Alan: is this to be merged somewhere and if yes, when? Do you need help?

It's included in the branch being reviewed by segfault, no worry.

#18 Updated by intrigeri about 1 year ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF