Failed to run meld as root

galbi · 22 October 2020 13:49

Hello all,

Usually I don’t run graphical applications with sudo, but use pkexec instead.

It works with pkexec thunar and pkexec mousepad. However, with meld I get the following error:

$ export LANG=C;pkexec meld
Unable to init server: Could not connect: Connection refused
Unable to init server: Could not connect: Connection refused
2020-10-22 15:22:48,701 CRITICAL Gtk: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
Traceback (most recent call last):
  File "/usr/bin/meld", line 384, in <module>
    setup_resources()
  File "/usr/bin/meld", line 236, in setup_resources
    Gtk.IconTheme.get_default().append_search_path(icon_dir)
AttributeError: 'NoneType' object has no attribute 'append_search_path'

This error looks similar to the one mentioned on the arch wiki page . But actually I don’t use wayland:

$ grep '/usr/s\?bin' /etc/systemd/system/display-manager.service
ExecStart=/usr/bin/lightdm

How comes it fails to start here, when other applications are fine? In the meantime I just use sudo meld and didn’t suffer any negative effects, though I’m aware it shouldn’t be done this way.

If anyone could shed some light on this I would be immensely grateful!

$ inxi -Fazy
System:
  Kernel: 5.8.16-2-MANJARO x86_64 bits: 64 compiler: N/A 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 
  root=UUID=61c9639e-7ec0-4912-ab0f-82d0d5bcd200 rw 
  Desktop: Xfce 4.14.2 tk: Gtk 3.24.20 info: xfce4-panel wm: xfwm4 
  dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:
  Type: Desktop System: Gigabyte product: N/A v: N/A serial: <filter> Chassis: 
  type: 3 serial: <filter> 
  Mobo: Gigabyte model: B75M-D3H v: x.x serial: <filter> 
  BIOS: American Megatrends v: F15 date: 10/23/2013 
CPU:
  Topology: Quad Core model: Intel Core i5-3570K bits: 64 type: MCP 
  arch: Ivy Bridge family: 6 model-id: 3A (58) stepping: 9 microcode: 21 
  L2 cache: 6144 KiB 
  flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27150 
  Speed: 1596 MHz min/max: 1600/3800 MHz Core speeds (MHz): 1: 1597 2: 1597 
  3: 1596 4: 1597 
  Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
  Type: l1tf 
  mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled 
  Type: mds mitigation: Clear CPU buffers; SMT disabled 
  Type: meltdown mitigation: PTI 
  Type: spec_store_bypass 
  mitigation: Speculative Store Bypass disabled via prctl and seccomp 
  Type: spectre_v1 
  mitigation: usercopy/swapgs barriers and __user pointer sanitization 
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, 
  IBRS_FW, STIBP: disabled, RSB filling 
  Type: srbds status: Vulnerable: No microcode 
  Type: tsx_async_abort status: Not affected 
Graphics:
  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics 
  vendor: Gigabyte driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:0162 
  Display: x11 server: X.Org 1.20.9 driver: intel display ID: :0.0 screens: 1 
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") 
  s-diag: 582mm (22.9") 
  Monitor-1: HDMI2 res: 1920x1080 hz: 60 dpi: 81 size: 600x340mm (23.6x13.4") 
  diag: 690mm (27.2") 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2) 
  v: 4.2 Mesa 20.1.8 compat-v: 3.0 direct render: Yes 
Audio:
  Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Gigabyte 
  driver: snd_hda_intel v: kernel bus ID: 00:1b.0 chip ID: 8086:1e20 
  Sound Server: ALSA v: k5.8.16-2-MANJARO 
Network:
  Device-1: Ralink RT5392 PCIe Wireless Network Adapter driver: rt2800pci 
  v: 2.3.0 port: f040 bus ID: 01:00.0 chip ID: 1814:5392 
  IF: wlp1s0 state: up mac: <filter> 
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Gigabyte driver: r8168 v: 8.048.03-NAPI modules: r8169 port: e000 
  bus ID: 03:00.0 chip ID: 10ec:8168 
  IF: enp3s0 state: down mac: <filter> 
Drives:
  Local Storage: total: 1.93 TiB used: 1.12 TiB (58.3%) 
  ID-1: /dev/sda vendor: Samsung model: SSD 840 Series size: 111.79 GiB 
  block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> 
  rev: 7B0Q scheme: MBR 
  SMART Message: Unknown smartctl error. Unable to get data. 
  ID-2: /dev/sdb vendor: Western Digital model: WD20EZRZ-00Z5HB0 
  size: 1.82 TiB block size: physical: 4096 B logical: 512 B speed: 3.0 Gb/s 
  rotation: 5400 rpm serial: <filter> rev: 0A80 scheme: GPT 
  SMART Message: Unknown smartctl error. Unable to get data. 
Partition:
  ID-1: / raw size: 29.81 GiB size: 29.21 GiB (98.01%) used: 19.07 GiB (65.3%) 
  fs: ext4 block size: 4096 B dev: /dev/sda1 
  ID-2: /home raw size: 81.98 GiB size: 80.57 GiB (98.28%) 
  used: 43.82 GiB (54.4%) fs: ext4 block size: 4096 B dev: /dev/sda5 
Swap:
  Kernel: swappiness: 60 (default) cache pressure: 100 (default) 
  ID-1: swap-1 type: file size: 512.0 MiB used: 0 KiB (0.0%) priority: -2 
  file: /swapfile 
Sensors:
  System Temperatures: cpu: 34.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 213 Uptime: 6h 53m Memory: 15.52 GiB used: 2.33 GiB (15.0%) 
  Init: systemd v: 246 Compilers: gcc: 10.2.0 Packages: pacman: 1356 lib: 405 
  Shell: Bash v: 5.0.18 running in: xfce4-terminal inxi: 3.1.05

TriMoon · 22 October 2020 15:14

sudo preserves more environment variables as pkexec IIRC…
Especially the path again IIRC.

galbi · 22 October 2020 15:28

I was under the impression that sudo with graphical applications could change rights in my home directory, even with the possibility of being unable to log in. Here is a link about it.

When gksu (or gksudo) was removed from the manjaro-repos, it has been told to users to use pkexec istead.

Fabby · 23 October 2020 19:00

Unless one of the meld programmers is on Manjaro, you’d be better off raising a bug request on their site: you’ll get more pointed answers that way…

If you’re using this meld, use sudo diff instead to compare system files…

P.S. You’re absolutely right about sudo and graphical programs.
P.P.S. If you use that program solely as root then the previous statement is null and void…

galbi · 23 October 2020 19:44

Thank you very much for your answer! I’ll try to raise a bug request on their site; and yes I’m using this meld you referred to.

Unfortunately, sudo diff is not practical to me. I need meld as a simple graphical tool to quickly compare and eventually merge .pacnew - files. It is the only thing where I couldn’t find a a good non-graphical alternative.

On the bright side, I use it solely for that indeed. As for now, I switched to do this instead:

pacdiff -o
sudo -i
meld /etc/thisandthatfile /etc/thisandthatfile.pacnew
exit

Fabby · 23 October 2020 19:50

I’ve marked the below answer as the solution to your question as it is by far the best answer you’ll get.

However, if you disagree with my choice, please feel free to take any other answer as the solution to your question or even remove the solution altogether: You are in control! (If you disagree with my choice, just send me a personal message and explain why I shouldn’t have done this or or if you agree)

P.S. In the future, please don’t forget to come back and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:

so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

galbi · 23 October 2020 19:54

Fair enough, and thank you very much! I’ll do as you told me!
Kind regards!

nikgnomic · 23 October 2020 20:09

meld works without sudo for comparing files in home folder

.pacnew files are usually in system folders and not home so sudo is needed

galbi · 23 October 2020 20:22

That’s exactly why root privileges are needed to compare, backup, edit and replace these files.

nikgnomic · 23 October 2020 20:37

the .pacnew files are not in home folder
so there is no potential for file permissions to be changed in home folder

galbi · 23 October 2020 21:06

My knowledge about this is rather limited, but as far as I know, running a graphical application as sudo might change privileges of potentionally vital configuration files in your home directory.

The target editing file of the application is irrelevant.

Take a close look at the arch wiki article here.

nikgnomic · 24 October 2020 01:04

If I thought meld was changing any file on my system (except for the one file I wanted to edit) I would want to find evidence of any changes to report the package as potential malware

meld only needs root privileges for write access to the system file
it could be used for a .pacnew comparison without sudo, but requires some additional steps:

user must click on padlock icon to unlock a system file for editing
the edited file must be saved to a location with user write access
the modified file can be moved to replace the system file with a terminal command

galbi · 24 October 2020 06:11

Yes, it’s just that I had around 20 .pacnew-files… this way it would take forever.

TriMoon · 24 October 2020 06:26

This would have been my personal choice as solution, especially if one takes into account what the Title of the OP says combined with what the intended usage was of of the OP’er…

moson · 24 October 2020 06:46

I generally agree with that, but in some cases it can make sense (like in your case) when you know what your’re doing.

File permission changes:

Well yeah, if you edit files with a sudo’ed program within your home folder this will screw up file permissions. I guess that concern comes from the scenarios where users just blindly sudo everything (“hey I heared about about that sudo which makes you the master. I just prepend all commands with it…”).

However your intention is clearly to make file changes that are owned by root.

Millions of lines of code run with elevated privileges:

Well, that’s true. However as long as your system and network are not already compromised and someone is waiting for you to run GUI as root I don’t see too much of an issue.
Text based programs can also make use of tons of foreign libraries, running millions of lines of code.

So. On a well secured system I don’t think running meld with root permissions (for the purpose of changing root owned files) for 5 minutes is a big issue here.

The alternative is to make your diff analysis via meld and then use a text based editor (with root permissions) to make the desired changes…

galbi · 24 October 2020 07:23

Thank you for the detailed explanation.

linux-aarhus · 31 October 2020 15:36

On EndeavourOS forum I saw this cool helper implementation of running meld as root

Warning when updating mkinitcpio 29-1 - Newbie - EndeavourOS

#!/usr/bin/bash
set -euo pipefail
export PATH=/usr/bin:/usr/sbin

for i in $(/usr/bin/pacdiff --output); do
	echo "Merging $i ..."
	/usr/bin/meld "admin://$i" "admin://${i/.pacnew/}";
done

nikgnomic · 31 October 2020 16:55

that looks like it was developed from the script that was on the old forum
A nifty way to deal with pacnew files using sudoedit - General Discussion - Manjaro Linux Forum
that used to work well for me, but i usually deal with them as soon as I see them mentioned in update information now

linux-aarhus · 1 November 2020 04:40

Maybe - creating helpers for handling such files tends to look alike.

This one is using admin: protocol which makes it pretty unique compared to the you linked from the old forum.

galbi · 1 November 2020 07:38

Wow, great! That is pretty fantastic stuff and very useful, thank you very much for sharing!