caja-extensions depends on gksu which is deprecated about caja-extensions HOT 19 OPEN

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

from caja-extensions.

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

from caja-extensions.

@monsta: @sunweaver nods...

from caja-extensions.

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.

from caja-extensions.

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

from caja-extensions.

@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/

from caja-extensions.

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;

from caja-extensions.

@pacho2 ktsuss was removed years ago from Debian.

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

from caja-extensions.

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

from caja-extensions.

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?

from caja-extensions.

@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.)

from caja-extensions.

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.

from caja-extensions.

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

from caja-extensions.

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

from caja-extensions.

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

from caja-extensions.

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

from caja-extensions.

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

from caja-extensions.

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

from caja-extensions.

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.

from caja-extensions.