Project

General

Profile

Bug #12000

Adjust doc for Stretch: starting graphical applications as root

Added by intrigeri 11 months ago. Updated 17 days ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
11/27/2016
Due date:
% Done:

0%

QA Check:
Feature Branch:
doc/12000-graphical-as-root
Type of work:
Website
Blueprint:
Easy:
Affected tool:

Description

(Reported by user, reproduced on sid by trying to start gedit.)


Related issues

Related to Tails - Bug #11921: No more "Root Terminal" launcher in Stretch Rejected 11/15/2016
Related to Tails - Feature #14760: Adjust doc for Wayland: starting graphical applications as root Confirmed 10/03/2017
Blocks Tails - Feature #13423: Core work 2017Q3: Technical writing Resolved 07/05/2017

Associated revisions

Revision 0003c234 (diff)
Added by anonym 9 months ago

Work around a gksu bug to make it possible to start graphical applications in the Root Terminal.

Refs: #12000

History

#1 Updated by intrigeri 11 months ago

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

#2 Updated by intrigeri 11 months ago

  • Priority changed from Normal to Elevated

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

#3 Updated by anonym 11 months ago

FWIW, sudo gedit in a "normal" terminal works fine.

#4 Updated by intrigeri 11 months ago

https://fedoraproject.org/wiki/Common_F25_bugs#Running_graphical_apps_with_root_privileges_.28e.g._gparted.29_does_not_work_on_Wayland says that 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), and bonus point: it'll work once we have moved to Wayland as well).

#5 Updated by intrigeri 10 months ago

  • 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 #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.

#6 Updated by intrigeri 10 months ago

spriver, you might want to have a look at my previous comment, in case you have some time to work on the doc update in the next few months :)

#7 Updated by anonym 9 months ago

Note that these Root terminals can be fixed by running:

export XAUTHORITY="/run/user/1000/gdm/Xauthority" 

It seems gksu sets it to something like /tmp/libgksu-MxA8hs/.Xauthority (I believe this is what is referred to as "Xauthority magic" in the gksu man page), but that dir/file isn't created so something is buggy. I guess we should try to repro on standard Debian Stretch, and report a bug.

Until it is fixed upstream we can work around it by putting something like this in e.g. /root/.bashrc:

if echo "${XAUTHORITY}" | grep -q '^/tmp/libgksu-'; then
    mkdir -p "$(dirname "${XAUTHORITY}")" 
    . /etc/live/config.d/username.conf
    cp "/run/user/$(id -u ${LIVE_USERNAME})/gdm/Xauthority" "${XAUTHORITY}" 
fi

This way we don't have to use the admin:// interface, which seemed a bit klunky (double password prompts), and we can stick with our old docs which is less work both for us and users that have to learn this. I bet front desk will get less reports about this too, since users will expect the Root Terminal to be able to open graphical applications.

#8 Updated by intrigeri 9 months ago

  • 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)

#9 Updated by anonym 9 months ago

intrigeri wrote:

I'm torn here.

Ok, got it. I still think I'll just sneak this fix into feature/stretch to potentially lighten front desk's burden ("PLEASE SIR FIX SO I CAN HAS OPTIMIZE MY TORRC!!!!1", might ring a bell? :)).

#10 Updated by intrigeri 9 months ago

  • 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 9 months ago

  • 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 #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! :)

#12 Updated by intrigeri 9 months ago

I think you misunderstood -- I meant:

Perfect!

#13 Updated by intrigeri 9 months ago

anonym wrote:

So, I've pushed the commit,

If there's a good reason why you used a hook rather than an include, please add a comment to the hook about it. A reference to "a gksu bug" would be welcome as well :)

#14 Updated by intrigeri 7 months ago

  • Priority changed from Normal to Elevated

#15 Updated by sajolida 6 months ago

  • 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 5 months ago

#17 Updated by intrigeri 5 months ago

  • 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 5 months ago

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

#19 Updated by sajolida 5 months ago

  • 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 5 months ago

  • 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!

#21 Updated by intrigeri 5 months ago

intrigeri wrote:

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".

Discussing this with anonym the other day, we agreed that we can (and probably should!) stick to X.Org for a while if we start tracking Debian testing this early, for hardware compatibility purposes. The breakage caused by moving to Wayland will then happen later, in 1-2 years, which gives us time to adjust our code & doc, and gives users time to get ready. Sorry for the above quoted text, I was overly enthusiastic wrt. the Wayland migration and the security benefits it'll give our users!

#22 Updated by sajolida 5 months ago

  • 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 5 months ago

  • Parent task deleted (#11916)

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

#24 Updated by intrigeri 4 months ago

Wait, there's stuff in the topic branch that wasn't merged anywhere. Don't we want to publish these changes?

#25 Updated by sajolida 4 months ago

#26 Updated by sajolida 4 months ago

#27 Updated by sajolida 17 days ago

  • 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 17 days ago

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

#29 Updated by intrigeri 17 days ago

sajolida wrote:

This doesn't need to happen before things break.

Fair enough! I've filed #14760 as a subtask of #12213 so we don't forget about it when we move to Wayland (and so the work done here is referenced and not lost).

Also available in: Atom PDF