Bug #12000

Feature #11916: Update doc for 3.0

Adjust doc for Stretch: starting graphical applications as root

Added by intrigeri 5 months ago. Updated about 1 month ago.

Status:ConfirmedStart date:11/27/2016
Priority:ElevatedDue date:
Assignee:sajolida% Done:

0%

Category:-
Target version:Tails_3.0
QA Check: Blueprint:
Feature Branch: Easy:
Type of work:End-user documentation 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

Associated revisions

Revision 0003c234
Added by anonym 3 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 5 months ago

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

#2 Updated by intrigeri 5 months ago

  • Priority changed from Normal to Elevated

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

#3 Updated by anonym 5 months ago

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

#4 Updated by intrigeri 5 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 4 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 4 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 3 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 3 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 3 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 3 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 3 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 3 months ago

I think you misunderstood -- I meant:

Perfect!

#13 Updated by intrigeri 3 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 about 1 month ago

  • Priority changed from Normal to Elevated

Also available in: Atom PDF