Elevated permission | `mousepad` execution denied

sudo mousepad /root/.bashrc: you should not do this :). You should use pkexec: pkexec mousepad /root/.bashrc.

That said, it probably won't work, and will answer you: "Failed to initialize xfconf". Mousepad 0.4.2 is quite old now (we are at Mousepad 0.5.4), but it would not change anything, except that the error message would be more complete:

Mousepad-CRITICAL **: 12:27:57.803: Failed to initialize xfconf: Error spawning command line ?dbus-launch --autolaunch=8d61eec3cc264f9badf0a6566da3c7f1 --binary-syntax --close-stderr?: Child process exited with code 1

I'll see what can be done on this side, but in the meantime, there is a simple and secure way to edit system files with Mousepad (or any other editor), without running the software with elevated privileges (which is always a bad idea with GUI software):

SUDO_EDITOR=mousepad sudoedit /root/.bashrc

This opens a temporary file before copying the result to the final destination, hence the display of a random file name in the GUI: don't worry about it.

assigned to @Tamaranch

Hello. On my system executing pkexec mousepad /root/.bashrc does not produce any message. Running a GUI text editor with elevated privileges – 'sudo <command>' – is a bad idea; I learned something today! I intend to avoid practises non-recommended by developpers. Is then pkexec <command> interpreted by Bash as elevated privileges? Would you recommend to apply pkexec to CLI text editors – e.g. nano, vi?

On my system executing pkexec mousepad /root/.bashrc does not produce any message

Do you mean that it works as expected or that nothing happens? If it works then something has changed in later versions of xfconf and/or the libraries it relies on.

Is then pkexec <command> interpreted by Bash as elevated privileges?

No, it is pkexec itself that, once started by bash, handles the elevation of privileges. And by default, pkexec runs command as root.

Would you recommend to apply pkexec to CLI text editors – e.g. nano, vi?

No, sudo is probably preferable in this case, although the most secure method to my knowledge remains sudoedit as above (but I'm not a security expert either…)

Release 0.4.2 does launch Mousepad. Up to come Fedora 34 XFCE Spin should bring a version closer to the one up-to-date.

Ok, thanks for the feedback. I guess Mousepad 0.5.x would also run with elevated privileges on your system (provided you can build it of course), but I'd be surprised if it would work as is once you upgrade to Xfce 4.16. Hopefully you'll be able to benefit from the patch I'll be adding soon…

closed with commit a981e60a

This issue is now mitigated when xfconf can't initialize, simply by doing without it, since Mousepad uses it only very anecdotally. There will still be warnings like

dconf-WARNING **: 18:32:22.894: failed to commit changes to dconf: Error spawning command line ?dbus-launch --autolaunch=8d61eec3cc264f9badf0a6566da3c7f1 --binary-syntax --close-stderr?: Child process exited with code 1

but that's another story (they are also present with Gedit by the way).

Installed packages on my system while this report was submitted:

$ rpm -qa gtk2 gtk3 gtk-xfce* glib2 glibc xfconf gtksourceview3 | sort | column
glib2-2.66.8-1.fc33.x86_64		gtk3-3.24.28-2.fc33.x86_64
glibc-2.32-4.fc33.x86_64		gtk-xfce-engine-3.2.0-12.fc33.x86_64
gtk2-2.24.33-1.fc33.x86_64		xfconf-4.14.4-1.fc33.x86_64
gtksourceview3-3.24.11-4.fc33.x86_64

Following Apps / mousepad/ Repository's guidance for installation from release tarball:

Now, new installed packages:

$ rpm -qa gtksourceview4
gtksourceview4-4.8.1-1.fc33.x86_64

$ ./configure
(...)
./configure: line 6426: intltool-update: command not found
checking for intltool >= 0.35.0...  found
configure: error: Your intltool is too old.  You need intltool 0.35.0 or later.

Then intltool >= 0.35.0 is an information eligible to be part of the Required packages of that documentation.

Now, new installed packages:

$ rpm -qa intltool
intltool-0.51.0-17.fc33.noarch

$ ./configure
(...)
checking for glib-2.0 >= 2.52.0... not found
*** The required package glib-2.0 was not found on your system.
*** Please install glib-2.0 (atleast version 2.52.0) or adjust
*** the PKG_CONFIG_PATH environment variable if you
*** installed the package in a nonstandard prefix so that
*** pkg-config is able to find it.

Indeed not found, since the component named glib-2.0 in output is named glib2 on my system. What a pity that i could not build Mousepad 0.5.4 in order to test, can it be run with elevated privileges on my system.

Then intltool >= 0.35.0 is an information eligible to be part of the Required packages of that documentation.

intltool is a build dependency, not a runtime dependency (not needed to run Mousepad). That's why it's not included in the list of required packages, I guess.

Indeed not found, since the component named glib-2.0 in output is named glib2 on my system.

As well, you may need to install the development versions of the required packages to be able to build, depending on you distribution. On Arch I don't need to do this (generally), but on Fedora 33, you need for example to install https://fedora.pkgs.org/33/fedora-aarch64/glib2-devel-2.66.1-3.fc33.aarch64.rpm.html. And it will probably be the same for the other required packages.

What a pity that i could not build Mousepad 0.5.4 in order to test, can it be run with elevated privileges on my system.

You should be able to do so in view of the characteristics listed above, and also to test the patch committed yesterday on git master if you want (but you have to follow "From source code repository" installation procedure for that, so git clone Mousepad repository and also install xfce4-dev-tools from your distribution).

Packages installed at once – 'dnf -y install {gtk4,glib2,glibc,xfconf,gtksourceview3}-devel xfce4-dev-tools'.
'./configure', 'make' and 'sudo make install': succeed.

$ pkexec mousepad /root/.bashrc
Unable to init server: Could not connect: Connection refused

(mousepad:25657): Gtk-WARNING **: 04:13:28.335: cannot open display:

'sudo mousepad /root/.bashrc' does launch Mousepad.

So now you have

sudo /usr/bin/mousepad /root/.bashrc does not launch Mousepad;
sudo /usr/local/bin/mousepad /root/.bashrc does launch Mousepad?

At first sight, I don't see why it works in one case and not in the other, but it confirms that it is possible to launch Mousepad 0.5.x (and therefore xfconf) with elevated privileges on your system.

Concerning pkexec, the problem is the following: it does not read the file /usr/local/share/polkit-1/actions/org.xfce.mousepad.policy installed by sudo make install, but continues to read (stupidly) the one located at /usr/share/polkit-1/actions/org.xfce.mousepad.policy. I had the problem recently and I couldn't figure out how to tell it where to go to read the file (the environment variable XDG_DATA_DIRS has no effect in particular).

So for it to work with pkexec, you have to either modify /usr/share/polkit-1/actions/org.xfce.mousepad.policy to replace /usr/bin/mousepad with /usr/local/bin/mousepad, or rename it and copy /usr/local/share/polkit-1/actions/org.xfce.mousepad.policy in its place.

Now, on my system :

sudo /usr/bin/mousepad /root/.bashrc does launch Mousepad v0.4.2;
sudo /usr/local/bin/mousepad /root/.bashrc does launch Mousepad v0.5.4;
pkexec /usr/bin/mousepad /root/.bashrc does launch Mousepad v0.4.2;
Following command does not launch Mousepad in any versions

$ pkexec /usr/local/bin/mousepad /root/.bashrc
Unable to init server: Could not connect: Connection refused

(mousepad:2496): Gtk-WARNING **: 06:04:40.340: cannot open display:

For this last case, see my comment above. In short, you can do:

sudo sed -i.bak 's%/usr/bin/mousepad%/usr/local/bin/mousepad%' /usr/share/polkit-1/actions/org.xfce.mousepad.policy

Then, pkexec /usr/local/bin/mousepad /root/.bashrc should work.

To return to the initial state:

sudo mv /usr/share/polkit-1/actions/org.xfce.mousepad.policy.bak /usr/share/polkit-1/actions/org.xfce.mousepad.policy

In the end, if you want to keep version 0.5.4 on your system, the right way would be to install it via your package manager. To do this, you have to tell it where to go to get this version. On Fedora I don't know how to do it: it would be the equivalent of Ubuntu's PPA, or AUR for Arch Linux, I guess it exists...

To keep the last version; that's an idea; a good one. By "where", i presume you meant the path to the tarball file – 'name'.tar.bz2.

No, I meant some kind of repository your package manager could be aware of via its configuration file, and where it could find an up-to-date Mousepad package (i.e. a precompiled binary, not a source tarball).

Again, I don't know Fedora, but searching for "fedora ppa", I find this: https://unix.stackexchange.com/questions/6766/is-there-is-a-ppa-service-equivalent-in-the-fedora-world

I don't know if the answers are relevant, but that's the idea.

Nothing to do! Then you were simply referring to existing RPM source repositories for Fedora, which are typically maintained by Fedora and Copr. Those sources, as well as all Linux distributions, cannot be expected to keep up all packages within their own update repositories up-to-date. An eventual existence of such source could be the one of the software developer if any – that would be in that context XFCE itself if it have had such source. You are the one that would be aware of its existence.

Executing mousepad does launch on my system that v.0.5.4, which was then installed from tarball available on the present GitHub project page, and not the v.0.4.2 from the Fedora repository; that satisfies me well enough.

changed milestone to %0.5.5

Elevated permission | `mousepad` execution denied

Designs

Child items 0

Activity