caja-extensions depends on gksu which is deprecated

[sc0w]

debian bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822595

quote from debian bug:

Hi,

caja-extensions depends on gksu, which is deprecated and
unmaintained. Thus we want to remove it from the archive.

caja-extensions should switch to a supported and securer way to
become root, particularly one that doesn't mean running your whole
application as root (including the GUI), e.g. using polkit.

Please try to do this before the Stretch release as we're going to
try to remove gksu this cycle.

We'll bump this to serious when the list of rdeps is small and we're
getting ready to removing gksu completely.

If you have any question don't hesitate to ask.

https://www.freedesktop.org/wiki/Software/polkit/
https://wiki.debian.org/PolicyKit

Cheers, Emilio

[monsta]

Easier said than done... I'd gladly switch it to polkit if someone shows me a good method of running arbitrary executables via it - without having to write a complex policy file for every known executable out there. 😕

[sunweaver]

@monsta: @sunweaver nods...

[monsta]

Looks like gksu is still there in Stretch... maybe they'll try to remove it in next dev cycle, after Stretch is released as stable.

[NP-Hardass]

Easier said than done... I'd gladly switch it to polkit if someone shows me a good method of running arbitrary executables via it - without having to write a complex policy file for every known executable out there. 😕

https://github.com/brunonova/nautilus-admin

Fork away :)

[pacho2]

Other option would be to replace gksu by ktsuss call:
https://github.com/nomius/ktsuss

[jbicha]

@monsta If you're willing to depend on gvfs 1.30 (found in Debian Stretch and Ubuntu 17.04 Beta and generally in distros that have packaged GNOME 3.22), you can use the new gvfs admin backend which should work in at least all gtk3 apps.

Just use the admin:/// prefix.

So to peak in the /root folder which is not viewable by normal users in Ubuntu, you could just navigate to admin:///root/

[pacho2]

Probably something like this would be the easiest to do in short term:
diff --git a/gksu/libcaja-gksu.c b/gksu/libcaja-gksu.c
index 18c8db1..a4767af 100644
--- a/gksu/libcaja-gksu.c
+++ b/gksu/libcaja-gksu.c
@@ -159,7 +159,7 @@ start_gksu_thread (void data)
gchar argv = (gchar) g_malloc (sizeof (gchar) * 3);
gchar full_cmd = (gchar) data;

• argv[0] = g_strdup ("gksu");

• argv[0] = g_strdup ("ktsuss");
  argv[1] = full_cmd;
  argv[2] = NULL;

[jbicha]

@pacho2 ktsuss was removed years ago from Debian.

I believe gvfs is not specific to gtk3 and is probably the best way to go.

[infirit]

I believe gvfs is not specific to gtk3 and is probably the best way to go.

it requires filemanager support for this to work. Caja and thunar both do not work with the admin backend. For caja one can backport https://git.gnome.org/browse/nautilus/commit/?id=5db7a29

I'd gladly switch it to polkit if someone shows me a good method of running arbitrary executables via it

You can't with polkit/pkexec. Each program will need an entry in an polkit action file otherwise it refuses to lauch, see example https://www.freedesktop.org/software/polkit/docs/0.105/pkexec.1.html

Fork away :)

Have fun, https://github.com/infirit/caja-admin

[NP-Hardass]

I think caja-admin (akin to nautilus-admin) sounds like a good way to go. @monsta Any thoughts on making the fork official? Either separately, or merging it into this package?

[jbicha]

@infirit That nautilus commit improved one aspect of integration with the gvfs admin backend. I don't believe it is required for the gvfs admin backend to work in a file browser. (That nautilus commit was for 3.24 and I believe the gvfs feature works in 3.22.)

[infirit]

So it is broken here on gentoo 😞 Sid is fine, also for caja. So i'll leave it up to the folks to deal with this further. Pickup caja-admin until they can use gvfs-admin or not.

[darkshram]

@infirit I have made work gvfs-admin with caja 1.18.0, gvfs 1.30 and gtk+ 3.22 (I use a custom Linux distro without systemd). It was kinda tricky. The command inside /usr/share/gvfs/mounts/admin.mount does not start automatically, no matter what you do o what fm you use in this scenario. But if the same command (pkexec /usr/libexec/gvfsd-admin "$@" --address $DBUS_SESSION_BUS_ADDRESS) is executed in a terminal (use a & at the end to send to background), gvfs-admin works and asks for password whenever is needed, without any more issues, until you logout or kill process. This means, with gvfs 1.30 the daemon needs to be launched manually in any OS without systemd. Seems to be a dbus-related issue in gvfs. In Fedora works out-of-the-box.

[lukefromdc]

I just stripped gksu out of my install because it depends on gconf and was the LAST thing in my install that does. I was able to remove a whole bunch of old otherwise unused stuff by removing it.
For now rebuilding caja-extensions without it, I normally use sudo in terminal to get root anyway.

Looking forward to anyone getting gvfs-admin to work in Caja as a replacement for caja-gksu, having to launch the daemon from a script because of systemd issues is no problem, as the script should be able to be autostarted from a launcher in someplace like /etc/xdg/autostart

[jbicha]

@lukefromdc Have you seen https://github.com/infirit/caja-admin/ (already packaged in Debian) ?

[lukefromdc]

That works well, so long as I install python-caja from the Debian repos. For some reason my local build of python-caja from git master did not work, giving errors. Posting a new issue to python-caja over that:

mate-desktop/python-caja#31

[infirit]

Try building PYTHON="python2" ./autogen.sh bla bla bla.

[lukefromdc]

Did not work:

Initializing caja-xattr-tags extension
Initializing caja-image-converter extension

(caja:12668): Caja-Python-WARNING **: 19:42:05.555: g_module_open libpython failed: /libpython2.7.so.1.0: cannot open shared object file: No such file or directory
ImportError: could not import gobject (error was: '/usr/lib/python2.7/dist-packages/gi/_gi.x86_64-linux-gnu.so: undefined symbol: _Py_ZeroStruct')

(caja:12668): Caja-Python-WARNING **: 19:42:05.564: pygobject initialization failed

(caja:12668): Caja-Python-WARNING **: 19:42:05.564: caja_python_init_python failed
Initializing caja-open-terminal extension

[infirit]

The most common cause of the error is you have a mismatch of what version of python you use link and run. Check sharedlib, below is mine linked to libpython2.7.so

$ ldd /usr/lib64/caja/extensions-2.0/libcaja-python.so | grep libpython
	libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f76728b6000)

So long as you use PYTHON="python2" at configure it should pick python2, perhaps you need to use python2.7.