Tails

#1 Updated by intrigeri 2016-11-27 16:21:29

• related to Bug #11921: No more "Root Terminal" launcher in Stretch added

#2 Updated by intrigeri 2016-11-27 16:23:53

• Priority changed from Normal to Elevated

Likely this breaks updating some bits of our doc => raising priority.

#5 Updated by intrigeri 2016-12-21 12:08:10

• Subject changed from Root terminal on Stretch does not allow starting graphical applications to Adjust doc for Stretch: starting graphical applications as root
• Assignee changed from intrigeri to sajolida
• Priority changed from Elevated to Normal
• Parent task set to Feature #11916
• Type of work changed from Research to End-user documentation

intrigeri wrote:
> one can do gedit admin:///etc/someconfigfile.conf => no need for a root terminal, it’s safer since gedit doesn’t run as root (not checked; my understanding is that only the file writing is done via gvfs as root),

Confirmed, it works and gedit runs as the amnesia user. One drawback is that one is asked for their admin password twice the first time one uses this feature (both in a current build from feature/stretch and on sid): once to start gvfsd-admin with pkexec, once to give access to the file to gedit. But next time one uses this feature, they’re only asked for their password once. It’s a minor annoyance IMO.

> and bonus point: it’ll work once we have moved to Wayland as well).

We’ll need to go through this at some point in the future anyway, so let’s do it now:

• all occurrences of “run ‘gedit $file’ in a root terminal” in our doc must be replaced with “run ‘gedit admin://$file’ in a terminal”;
• all occurrences of “run ‘nautilus $directory’ in a root terminal” in our doc must be replaced with “run ‘nautilus admin://$directory’ in a terminal”;
• all occurrences of “run ‘$command_that_opens_a_GUI’ in a root terminal”, when that GUI doesn’t support the GNOME gvfs, must be replaced with “run ‘sudo $command_that_opens_a_GUI’ in a terminal” (this won’t be Wayland-compatible but it least it’ll fix the problem); I don’t know if we have any such thing in our current doc; it would be nice to list them so we better know how much the migration to Wayland will cost us.

#8 Updated by intrigeri 2017-02-02 09:56:35

• Type of work changed from End-user documentation to Discuss

I’m torn here.

I agree the double password prompt on first use of the admin:// interface is annoying. OTOH it does have some minor advantages (security, gedit and nautilus will take into account user configuration). Two things that might help decide:

• At some point (likely Tails 4.0, possibly 3.x) we’ll switch to Wayland, and then we’ll have to switch to admin:// for gedit and nautilus, and break current user expectations/habits. So any workaround we put in place only affects when this happens, not whether it does. Is it worth it?
• Do GUI apps started from a Root Terminal support accessibility technologies currently? If they don’t, then switching to admin:// fixes one accessibility problem. If we have a hard time making up our mind based on the above pros and cons, this one might make the difference. (GUI apps started from a Root Terminal on 2.x do support orca)

#10 Updated by intrigeri 2017-02-02 16:34:27

• Assignee changed from sajolida to anonym
• Type of work changed from Discuss to Code

As you wish. Please retitle this ticket accordingly :)

#11 Updated by anonym 2017-02-02 16:55:04

• Assignee changed from anonym to sajolida
• Type of work changed from Code to End-user documentation

intrigeri wrote:
> As you wish. Please retitle this ticket accordingly :)

I think you misunderstood — I meant:

• I get your concern (e.g. vs Wayland) so let’s convert our docs like you proposed in Bug #12000#note-5
• let’s sneak in my fix (of this regression since Jessie) to reduce the burden on front desk for users that expect this to work in general (not by following our docs)

So, I’ve pushed the commit, but it’s orthogonal to this ticket. Now I’m out of here and leave the rest to the doc writers! :)

#14 Updated by intrigeri 2017-03-17 12:54:30

• Priority changed from Normal to Elevated

#15 Updated by sajolida 2017-05-07 10:38:24

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

Sorry it took me so long to check this out.

I spotted that we are instructing to use a Root Terminal on these pages:

• doc/encryption_and_privacy/truecrypt.mdwn: No graphical applications so nothing to update.
• doc/first_steps/persistence/check_file_system.mdwn: No graphical applications so nothing to update.
• install/debian/usb.mdwn: No graphical applications so nothing to update.
• doc/first_steps/persistence/upgrade.mdwn: This one is 4 years old so I propose that we delete it.
• doc/first_steps/startup_options/administration_password.mdwn: If we have the workaround of anonym in the code I propose that we do nothing on this page. Otherwise we could have documented the workaround.
• doc/first_steps/persistence/copy.mdwn: So we’re basically left with this one where we are using Nautilus as root to copy files between the persistence and a backup while preserving persmissions. Unfortunately, it seems like persmissions are mangled if relying on the admin:/// trick. To reproduce:
  • Open admin:///live/persistence/TailsData_unlocked in a tab.
  • Open admin:///tmp/backup in another tab.
  • Copy persistence.conf from the persistence to the backup.
  • Check the permissions on the persistence.conf in the backup.
  • The backup belongs to amnesia:root instead of root:root.

Would there be any way to prevent this with the admin:/// thingie? Otherwise we might have to rely on anonym’s workaround and keep that documentation as it is now.

Assigning to intrigeri for more hardcore Wayland compatible magic…

#16 Updated by sajolida 2017-05-10 15:15:48

• blocks Feature #12432: Technical writing core work 2017Q2 added

#17 Updated by intrigeri 2017-05-11 10:39:07

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

Hi!

> I spotted that we are instructing to use a Root Terminal on these pages:

There’s also doc/encryption_and_privacy/your_data_wont_be_saved_unless_explicitly_asked.mdwn.

> * doc/first_steps/persistence/upgrade.mdwn: This one is 4 years old so I propose that we delete it.

ACK, please go ahead (after checking for backlinks).

> * doc/first_steps/startup_options/administration_password.mdwn: If we have the
> workaround of anonym in the code I propose that we do nothing on this page.

Just to be clear: as discussed earlier on this ticket, if we do that we’re just postponing the work and the time when users have to get used to the new tools (i.e. when we move to Wayland, likely in 2017Q4 or 2018Q1 if we choose to start tracking Debian testing). That’s fine, I just want to make sure you’re aware of it :)

So if you indeed decide to do nothing now about it, please file a ticket for Tails 4.0 about removing the workaround (it won’t work anymore anyway) and adjusting our doc accordingly, linking to this very ticket: it would be sad to lose all the research I’ve done + my indications of how the doc should be updated. Thanks!

> * doc/first_steps/persistence/copy.mdwn: So we’re basically left with this one where
> we are using Nautilus as root to copy files between the persistence and a backup
> while preserving persmissions. Unfortunately, it seems like persmissions are mangled
> if relying on the admin:/// trick. To reproduce:
> Open admin:///live/persistence/TailsData_unlocked in a tab.
> Open admin:///tmp/backup in another tab.
> Copy persistence.conf from the persistence to the backup.
> Check the permissions on the persistence.conf in the backup.
> The backup belongs to amnesia:root instead of root:root.

Argh :(

But wait, this doc does not suggest to copy persistence.conf, but instead to generate a new one from the new Tails, and there’s a good reason for that: copying persistence.conf in Tails 2.x will result in a config file that live-persist will reject, as it won’t have the correct ACLs. So the scenario you described is not a regression in practice AFAIK. What other files are affected? Only APT, CUPS and NM, right?

> Would there be any way to prevent this with the admin:/// thingie?

I didn’t manage to find any such thing. But this doc page already requires the user to run a command as root to adjust files ownership, so perhaps we could also tell them to give the few relevant folders back to root, which can be done in Nautilus, and will keep working in Tails 4.0.

#18 Updated by sajolida 2017-05-18 16:27:40

• Feature Branch set to doc/12000-graphical-as-root

#19 Updated by sajolida 2017-05-18 17:10:27

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

> ACK, please go ahead (after checking for backlinks).

Done in d293a220cf.

>> * doc/first_steps/startup_options/administration_password.mdwn: If we have the
>> workaround of anonym in the code I propose that we do nothing on this page.
>
> Just to be clear: as discussed earlier on this ticket, if we do that we’re just postponing the work and the time when users have to get used to the new tools (i.e. when we move to Wayland, likely in 2017Q4 or 2018Q1 if we choose to start tracking Debian testing). That’s fine, I just want to make sure you’re aware of it :)
>
> So if you indeed decide to do nothing now about it, please file a ticket for Tails 4.0 about removing the workaround (it won’t work anymore anyway) and adjusting our doc accordingly, linking to this very ticket: it would be sad to lose all the research I’ve done + my indications of how the doc should be updated. Thanks!

On this page we are not instructing to start any graphical application
in particular. We are giving hints on how to start a root terminal. This
section is then linked from some advanced topics where we don’t run
graphical applications. If one day we add any, we will test them and see
that they fail before publishing them.

From your research I understand that there is no generic way of starting
all the possible graphical applications from the command line with
Wayland. So I don’t know what we could instruct here that would work as
a generic solution.

What would you do?

Note that once in Wayland we might think it’s worth documenting (or
pointing to some external documentation) about how running graphical
applications from the terminal works.

> But wait, this doc does not suggest to copy persistence.conf […]

Sorry I took a bad example indeed.

> […] What other files are affected? Only APT, CUPS and NM, right?

All files, folders, and subfolders are attributed to amnesia:root, be
their originally attributed to root:root or amnesia:amnesia. I don’t
think that would create many problems but I can’t be sure either.

> […] so perhaps we could also tell them to give the few relevant folders back to root, which can be done in Nautilus

Files and subfolders are affected as well. So we would have to adapt the
command lines to fix all the permissions in depth.

That’s clearly possible but, taking a step back, I wonder why:

• We are trying to fix now stuff that will break in 4.0 when anonym
  provided a workaround for the next ~1.5 years and that doesn’t require
  people to face issues and hunt for solutions in the doc. Until Debian
  10.0 is released, things might still change in this field and we might
  still anyway have to modify this documentation again. And I hope we’ll
  have something better for backups by then :)

• We shouldn’t report the permission mangling as a bug in Nautilus. Why
  does it do that in the first place???

Still, we should clearly do something to keep your research in sight
when updating the doc for 4.0. We can create a ticket for that.

#20 Updated by intrigeri 2017-05-19 12:10:12

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

>>> * doc/first_steps/startup_options/administration_password.mdwn: If we have the workaround of anonym in the code I propose that we do nothing on this page.
>>
>> Just to be clear: as discussed earlier on this ticket, if we do that we’re just postponing the work and the time when users have to get used to the new tools (i.e. when we move to Wayland, likely in 2017Q4 or 2018Q1 if we choose to start tracking Debian testing). That’s fine, I just want to make sure you’re aware of it :)
>>
>> So if you indeed decide to do nothing now about it, please file a ticket for Tails 4.0 about removing the workaround (it won’t work anymore anyway) and adjusting our doc accordingly, linking to this very ticket: it would be sad to lose all the research I’ve done + my indications of how the doc should be updated. Thanks!

> On this page we are not instructing to start any graphical application in particular. We are giving hints on how to start a root terminal. This section is then linked from some advanced topics where we don’t run graphical applications. If one day we add any, we will test them and see that they fail before publishing them.

OK, thanks for clarifying (I should have checked myself whether we relied on these instructions for starting graphical applications, sorry for wasting your time).

> From your research I understand that there is no generic way of starting all the possible graphical applications from the command line with Wayland. So I don’t know what we could instruct here that would work as a generic solution.

> What would you do?

Indeed, we’ll need to address each issue separately (probably the way I’ve documented it above) and there won’t be any generic solution.

So the only remaining question is IMO: do we want to document on that page that the Root Terminal should not be used for starting graphical apps, and when? I understood that we don’t explicitly pretend it can, but with anonym’s workaround we’re keeping this problematic behaviour on life support, and are still contributing to the popular belief that it’s an OK thing to do: users will keep training themselves to rely on it. This being clarified, I trust you to make the right decision wrt. documenting this now (along with some of the better alternatives I’ve listed earlier on this ticket), or wait until the time when we have to entirely break this “feature” :)

>> […] What other files are affected? Only APT, CUPS and NM, right?

> All files, folders, and subfolders are attributed to amnesia:root, be their originally attributed to root:root or amnesia:amnesia. I don’t think that would create many problems but I can’t be sure either.

>> […] so perhaps we could also tell them to give the few relevant folders back to root, which can be done in Nautilus

> Files and subfolders are affected as well. So we would have to adapt the command lines to fix all the permissions in depth.

Ouch, it’s worse than I thought. Wow, that seems tricky to get right. Let’s not open this scary box now.

> That’s clearly possible but, taking a step back, I wonder why:

> * We are trying to fix now stuff that will break in 4.0 when anonym provided a workaround for the next ~1.5 years and that doesn’t require people to face issues and hunt for solutions in the doc. Until Debian 10.0 is released, things might still change in this field and we might still anyway have to modify this documentation again. And I hope we’ll have something better for backups by then :)

For the record, the “next ~1.5 years” figure is a far fetched assumption: as said above, it may rather be until “2017Q4 or 2018Q1 if we choose to start tracking Debian testing”. But I agree we can go back to the workaround (running Nautilus as root) for 3.0: the timing we’re working with doesn’t really allow us to do anything better. So reassigning to you as Dev Needed (I didn’t follow if there’s anything to do at all or if we’re leaning towards “keep what we have for now”).

And it’s good news that you noticed this bug now: we’ll have more time to get the Nautilus bug fixed upstream before we really have to use Nautilus with admin:/// to copy files around :)

> * We should report the permission mangling as a bug in Nautilus. Why does it do that in the first place???

Yes, absolutely. Can you want to do that or should I? If you want me to do it, please give me a dedicated ticket so we can close this one :)

We’re getting there!

#22 Updated by sajolida 2017-05-22 20:59:39

• Priority changed from Elevated to Low
• Target version deleted (Tails_3.0)
• Type of work changed from End-user documentation to Website

When I said “~1.5 year” I forgot about the plan to track testing :)

I’ll write a note about that on /doc/first_steps/startup_options/administration_password but I don’t want to feel the pressure to do this before 3.0 so I’m removing the target version.

#23 Updated by sajolida 2017-06-02 16:04:48

• Parent task deleted (Feature #11916)

Removing the parent task so I can close Feature #11916 :)

#25 Updated by sajolida 2017-07-05 18:59:59

• blocks Feature #13423: Core work 2017Q3: Technical writing added

#26 Updated by sajolida 2017-07-05 19:00:02

• blocked by deleted (Feature #12432: Technical writing core work 2017Q2)

#27 Updated by sajolida 2017-10-02 17:53:31

• Status changed from Confirmed to Rejected
• Assignee deleted (sajolida)
• QA Check deleted (Dev Needed)

This doesn’t need to happen before things break.

#28 Updated by intrigeri 2017-10-03 05:26:54

• related to Feature #14760: Adjust doc for Wayland: starting graphical applications as root added