Fix for Freedesktop Invocation

[s***@yopmail.com]

I use two files to set emelfm2 as default file manager
in Openbox.

# /etc/profile.d/90-mime-defaults.sh
xdg-mime default emelfm2.desktop inode/directory
xdg-mime default emelfm2.desktop inode/mount-point

# diff output between
# /usr/share/applications/emelfm2.desktop (stock Arch Linux install)
# /usr/local/share/applications/emelfm2.desktop (my override file)
-Exec=emelfm2
+Exec=emelfm2 -2

The revised .desktop file overrides by path precedence.
The stock file remains as installed in /usr/share/applications.

The -2 switch makes emelfm2 act like other file managers
when invoked with a file arg. Most file managers (all?)
accept a file path arg and open it on launch.

I recommend emelfm2 adopt my method or change syntax to
act like other file managers. It took me quite a while to
find this fix!

Thanks for such a great app. I hope releases will be more
frequent too...

Best regards
Dave

[t***@onepost.net]

On Fri, 11 Oct 2013 04:17:14 +0000

Post by s***@yopmail.com
I use two files to set emelfm2 as default file manager
in Openbox.
# /etc/profile.d/90-mime-defaults.sh
xdg-mime default emelfm2.desktop inode/directory
xdg-mime default emelfm2.desktop inode/mount-point
# diff output between
# /usr/share/applications/emelfm2.desktop (stock Arch Linux install)
# /usr/local/share/applications/emelfm2.desktop (my override file)
-Exec=emelfm2
+Exec=emelfm2 -2
The revised .desktop file overrides by path precedence.
The stock file remains as installed in /usr/share/applications.
The -2 switch makes emelfm2 act like other file managers
when invoked with a file arg. Most file managers (all?)
accept a file path arg and open it on launch.

As does this one - but tailored for 2-pane operation.

Post by s***@yopmail.com
I recommend emelfm2 adopt my method or change syntax to
act like other file managers. It took me quite a while to
find this fix!

emelfm2 --help

lists:-

usage: emelfm2 [option]
Program options:
-1,--one=DIR set 1st pane's start directory to DIR
-2,--two=DIR set 2nd pane's start directory to DIR

among other things.

What led you to prefer pane 2 over 1 ?

Subject to the answer for this, your proposal would be quite ok by me.

Post by s***@yopmail.com
Thanks for such a great app. I hope releases will be more
frequent too...

In the past, release intervals were typically around 2 months, but that's not needed now. It's quite stable.

Or I should say, it has been, until gtk3 started mucking things around.

Regards
Tom

[s***@yopmail.com]

Post by t***@onepost.net
As does this one - but tailored for 2-pane operation

http://www.4pane.co.uk/manual/Running.htm
This app has 4, yet works like other FMs.

The key is not "You CAN invoke emelfm2 with a path, read
the HELP dude" but rather, "GOOFINESS between emelfm2 and
.desktop causes needless PAIN in FreeDesktop systems."

Ranger has 2 panes, 4Pane has 4, and dolphin can show many
(eg File/NewTab and View/Split); yet only emelfm2 has
invocation oddness with a path as 1st arg. Try it:

dolphin /usr/share/doc
ranger /usr/share/doc
pcmanfm /usr/share/doc
rox /usr/share/doc
emelfm2 /usr/share/doc

My vote would be to accept a path arg like other FMs.
Keep the -1 -2 switches too.

Post by t***@onepost.net
What led you to prefer pane 2 over 1 ?

I keep my working folder in pane 1. For end user boxes,
I hardwire pane 1 to a "sane place" they like. It isn't
always $HOME but can be. Users get lost. A quit/relaunch
restores their sanity. Using the other pane for system
invocations avoids confusing them.

Post by t***@onepost.net
It's quite stable.

Agreed...kinda. The release prior crashed regularly on
renaming. Other improvements beckon.

The app icon could use modern artistic flair, SVG, whatever.

The app could (optionally) do desktop icons via XDG_DESKTOP_DIR,
like old iDesk, without wallpaper. Plenty of apps run wallpaper,
fewer desk icons in Openbox.

Still it's my go-to app. I have never found anything quite as
close to the magic sweet spot. Thanks so much.

My main complaint is sudo/root usage. There again, the sys
interactions are the gotchas. It's not the app but how it
gets called, reads configs, etc. Other FMs run as root user
aren't so itchy.

I do custom busywork to make emelfm2 a sysadmin tool.
There's a separate root .desktop and a polkit config.
Menus show an admin version separate from the normal one.
(Yes I know about the sudo button and never use it.)

Here are my root user setup files, which come to think of,
I need to fix with the -2 switch someplace, egad.
XDG_CONFIG_VOLATILE is my own env var, not a standard XDG one.

I'd love emelfm2 to ship stock with "admin version" configs.
Maybe that's a distro call, I dunno. It helps having both a
normal and "admin" version in app menus. Bonus points if the
root app can share the normal one's config folder without
mucking it up. I spent a lot of time running a special script
to handle those gotchas. It worked OK for a long while but
got tired of the weirdness and general maintenance involved.


$ cat /usr/share/polkit-1/actions/org.archlinux.custom.pkexec.emelfm2.policy

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>

<action id="org.archlinux.custom.pkexec.emelfm2">
<message>Authentication is required to manage system files</message>
<icon_name>emelfm2</icon_name>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/emelfm2</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
</action>

</policyconfig>



$ cat /usr/local/share/applications/emelfm2-pkexec.desktop

[Desktop Entry]
Version=1.0
Type=Application
Name=emelFM2 with Admin Rights
GenericName=file manager
Comment=2-pane Gtk+2 file manager
Exec=sh -c "pkexec emelfm2 --config\=\${XDG_CONFIG_VOLATILE}/.emelfm2"
Icon=emelfm2.png
Terminal=false
StartupNotify=false
Categories=System;FileTools;GTK;FileManager;Application;Utility;

[t***@onepost.net]

On Sat, 12 Oct 2013 10:44:24 +0000

Post by s***@yopmail.com
My vote would be to accept a path arg like other FMs.
Keep the -1 -2 switches too.

Svn code now supports this.

If a path is specified, it may be relative or absolute. If pane2 is hidden or nearly-so, it will be expanded to show the specified directory.

The desktop file command-strings include -2, as you suggested, though that's probably redundant now.

Post by s***@yopmail.com
Agreed...kinda. The release prior crashed regularly on
renaming.

Has that stopped ?

Post by s***@yopmail.com
The app icon could use modern artistic flair, SVG, whatever.

It's available as a svg file. As to whether it should change, that's just branding. Suggestions welcome.

Post by s***@yopmail.com
The app could (optionally) do desktop icons via XDG_DESKTOP_DIR,
like old iDesk, without wallpaper. Plenty of apps run wallpaper,
fewer desk icons in Openbox.

Not sure what you mean here.

Post by s***@yopmail.com
My main complaint is sudo/root usage. There again, the sys
interactions are the gotchas. It's not the app but how it
gets called, reads configs, etc. Other FMs run as root user
aren't so itchy.

It's fair to say that the application wasn't designed to be a 'run-as-somebody' sort of thing.

I'll come back to this, and your suggestions, when I get some time.

Regards
Tom

[s***@yopmail.com]

Post by t***@onepost.net

crashed regularly on renaming

Has that stopped ?

Believe so - thanks to bugfix release - please more

Post by t***@onepost.net

like old iDesk, without wallpaper

Not sure what you mean here.

Some FMs manage desktop icons and/or wallpaper for the WM. Openbox needs
help from someplace. The big DEs have their own stuff, not always inside
the FM, but sometimes.

I'd like separated manage/don't-manage options for icons and wallpaper.
Some FMs are both-or-nothing. Wallpaper apps are easy to find; icon
apps, not so much.

The FreeDesktop $XDG_DESKTOP_DIR is where icons live, nominally
${HOME}/Desktop. Icons should be movable/drag-n-droppable as in rox. Yet
I don't recall that rox properly followed FreeDesktop specs with its
"pinboard" notions. As usual rox wants people in its own little roxy
world. However the speed and performance/stability are top notch.

Just a thought about functionality for the future since you were
pondering if there's anything left to do. As someone who defaults to
emelfm2, I think it would be sweet.

Best
D

[t***@onepost.net]

On Sun, 13 Oct 2013 05:08:20 +0000

Post by s***@yopmail.com

Post by t***@onepost.net

crashed regularly on renaming

Has that stopped ?

Believe so - thanks to bugfix release - please more

Post by t***@onepost.net

like old iDesk, without wallpaper

Not sure what you mean here.

Some FMs manage desktop icons and/or wallpaper for the WM. Openbox needs
help from someplace. The big DEs have their own stuff, not always inside
the FM, but sometimes.
I'd like separated manage/don't-manage options for icons and wallpaper.
Some FMs are both-or-nothing. Wallpaper apps are easy to find; icon
apps, not so much.

I'm one of those who thinks it's not sensible for a file manager to also manage a desktop.

If you've been following recent discussion on this ML, you might have inferred that sooner or later, something other than gtk4 will be needed for emelFM2. We won't be alone in this, I'm sure. Maybe then there'll be a surge of interest in things such as you want. What's bad about iDesk?

Regards
Tom

[s***@yopmail.com]

Post by t***@onepost.net
it's not sensible for a file manager to
also manage a desktop

Other FMs handle desktop icons, including the Big
Ones from GNOME and KDE, so your opinion is exceptional.

When it comes to icons, no other app makes sense.
The "desktop" is just an idiom for file management.

It's just inotify-monitoring $XDG_DESKTOP_DIR and
drawing icons on X11 root window, recording user
positions in a store. That and XDnD about does it.

A lot of end users really like and organize on
desktops. I try to help.

iDesk is terribly old and stale, unmaintained now.
Rox is actually quite good in many respects but
forces you into its "universe of Rox" when you want
good MIME handling.

Post by t***@onepost.net
If you've been following

Toolkit debate is ghastly boring. I know them all.
They're all broken.

SpaceFM was also talking about "the future"
toolkit decision, but its owner disappeared,
tired I guess. No more development.

I don't care what toolkit emelfm2 wants so long
as emelfm2 remains stable. Use anything, but
keep core logic decoupled from toolkit APIs
if you can.

Thank you for the feedback, Tom. If icons don't
appeal then go for the root/admin usage configs!
That'd be more useful to me.

[t***@onepost.net]

On Fri, 18 Oct 2013 00:37:36 +0000

Post by s***@yopmail.com
Thank you for the feedback, Tom. If icons don't
appeal then go for the root/admin usage configs!
That'd be more useful to me.

svn code now includes a preliminary version of a plugin for changing authority and running things as a different user.

Really, it's at proof-of-concept stage. I've not yet figured out how to get PAM to approve things, nor whether polkit can do any user other that self or root, nor what are the needed changes to the context after approval is gained. Su(1) might be a template for the latter. There's a commandline option -u, as previously posted. There will be actions to replicate the effects of commands su, sudo. Ignore pkexec altogether.

Build with WITH_SU=1, optionally also WITH_POLKIT=1

Regards
Tom

[s***@yopmail.com]

Post by t***@onepost.net
svn code now includes a preliminary version of a
plugin for changing authority and running things
as a different user.
Really, it's at proof-of-concept stage.
I've not yet figured out ...

Thanks Tom! Wow what a guy. I'm looking forward to
these developments.

Not sure I like any plugin concept....hmmm....
separate .desktop for admin seems more apropos
than a privilege escalation plugin. If you invoke
the app with privilege, you don't need any more
special app logic or plugins. It's all a system
issue. The system confers privilege as it should.

As I originally reported, my whole problem with
emelfm2 is NOT the app, but system interactions.
I'm not a guru on Linux security and I guess you
need to worry about more than one distro. FWIW my
.dekstop and polkit configs from earlier work fine
on Arch.

Me, I would focus on changing how emelfm2 interacts
in ways that don't alter the base app or even allow
privilege escalation, an internal security risk and
what seems excess work (?).

So it boils down to Exec lines in .desktop files and
various security config scripts.

I guess one thing to remember is how a privileged
app changes appearance. If a plugin scheme doesn't do
so, then I would not use it. One glance at my admin
version of emelfm2 tells me: privileged. Also at
bottom left corner emelfm2 itself says "root" in
the very bottom-most status line.

This admin version (here) uses root's XDG vars
instead of the normal user's XDG vars, so all's very clean.
The two emelfm2 config folders are completely separate.
Specifically $XDG_CONFIG_HOME is the variable of interest,
usually defined as ~/.config folder for each user.
I didn't do anything beyond the configs already shown
to accomplish that separation. Somehow polkit knows.

Not sure I got your point about more than two users,
don't see any need for more. Any logged in user will be
working as $USER or invoke as superuser, so I count
two choices, no matter who's logged in. My menus show
2 versions of emelfm2 from the .desktop files I use.
One is privileged, one not. Same story for any $USER login.

By the way I use exactly the same tricks with other apps
useful in admin work - eg Geany for editing sys configs.
To my mind the whole issue is not about new app logic
or plugins but package configuration.

Forgot to mention another tweak that would be nice,
the pane background color needs an option inside
panes/colors under the advanced config screen. Right now
AFAIK it's all-white, only-white, or maybe depends on
GTK theme. I'd like a setting specifically for background.

And if you haven't heard of it, I recommend redshift for
general computer use.

Best

[t***@onepost.net]

On Thu, 31 Oct 2013 07:16:21 +0000

Post by s***@yopmail.com
Not sure I like any plugin concept....hmmm....
separate .desktop for admin seems more apropos
than a privilege escalation plugin. If you invoke
the app with privilege, you don't need any more
special app logic or plugins. It's all a system
issue. The system confers privilege as it should.

Functionality that provokes extra dependencies is almost always optional. Functionality that's non-trivial, non-core and not necessarily of use to many users will be a plugin.

Post by s***@yopmail.com
As I originally reported, my whole problem with
emelfm2 is NOT the app, but system interactions.
I'm not a guru on Linux security and I guess you
need to worry about more than one distro. FWIW my
.dekstop and polkit configs from earlier work fine
on Arch.
Me, I would focus on changing how emelfm2 interacts
in ways that don't alter the base app or even allow
privilege escalation, an internal security risk and
what seems excess work (?).

The core code has about 30 extra lines of code, merely to process any -u commandline option.

The plugin actions which [de-]escalate privilege also allow internal actions (as distinct from external commands) to be run with the changed privilege. There's nothing much to them (and it's mostly done). They won't actually do anything, until I figure out how to appropriately change the operating context.

A build-time choice (WITH_SU_ACTIONS=0) causes those actions to be omitted e.g. for security reasons, leaving only the session-user-change interface. For a higher level of security - don't build/install the plugin.

Post by s***@yopmail.com
So it boils down to Exec lines in .desktop files and
various security config scripts.

We need to decide a couple of default PAM scripts - one to authorise a su-like change, the other for sudo-like. I don't yet understand enough about PAM to get these working. A suitable policykit policy file is fairly trivial. Your alternative .desktop file would just include "-u 0", I suppose.

Post by s***@yopmail.com
I guess one thing to remember is how a privileged
app changes appearance. If a plugin scheme doesn't do
so, then I would not use it. One glance at my admin
version of emelfm2 tells me: privileged.

How is yours visibly distinguished ?

Also at

Post by s***@yopmail.com
bottom left corner emelfm2 itself says "root" in
the very bottom-most status line.

The session-user-change process, and the plugin actions where relevant, change the username displayed in the main window status bar, and flag that text. Currently it's hard-coded bold red, but it should become the configured 'negative color', I think, if Pango text markup language is sufficiently flexible.

Post by s***@yopmail.com
This admin version (here) uses root's XDG vars
instead of the normal user's XDG vars, so all's very clean.
The two emelfm2 config folders are completely separate.
Specifically $XDG_CONFIG_HOME is the variable of interest,
usually defined as ~/.config folder for each user.
I didn't do anything beyond the configs already shown
to accomplish that separation. Somehow polkit knows.

That's one of the matters to be investigated. Su and pkexec both have their own approach to 'changing personality', including environment variables. For the most part, after changing user, the number of environment variables is minimal, and in a newly-forked shell. It's not yet clear to me what's the best approach for a non-terminal application.

Post by s***@yopmail.com
Not sure I got your point about more than two users,
don't see any need for more. Any logged in user will be
working as $USER or invoke as superuser, so I count
two choices, no matter who's logged in.

Some of us work with multiple users, apart from root. For example, I always log in as a separate user for development, a sandbox. For coding purposes, another user is another user, the process for changing is much the same, root is nothing special. Or, maybe root user is different for policykit.

My menus show

Post by s***@yopmail.com
2 versions of emelfm2 from the .desktop files I use.
One is privileged, one not. Same story for any $USER login.
By the way I use exactly the same tricks with other apps
useful in admin work - eg Geany for editing sys configs.
To my mind the whole issue is not about new app logic
or plugins but package configuration.
Forgot to mention another tweak that would be nice,
the pane background color needs an option inside
panes/colors under the advanced config screen. Right now
AFAIK it's all-white, only-white, or maybe depends on
GTK theme. I'd like a setting specifically for background.

UI widgets' styling (apart from text colour and, if the user so chooses, font) are per the current theme.

Post by s***@yopmail.com
And if you haven't heard of it, I recommend redshift for
general computer use.

OK, thanks.

Regards
Tom

[t***@onepost.net]

On Thu, 31 Oct 2013 07:16:21 +0000
***@yopmail.com wrote:

After a lot of investigation and experimentation on this, I've concluded that it's not possible to bend the rules sufficiently to 'change personality' from within a running process/application. On reflection, this is a good thing for system security.

Some implications:

1. It should be possible for e2 to re-start itself as another user, after having obtained the relevant authority.

2. A sudo-like action to apply a temporary change can't be implemented.

The distinction between a self-restart and starting via sudo, pkexec, gksu etc would (if so wanted) be a consistent UI for entering a password, and possibly, direct use of PAM so as to bypass the polkit dependency.

I haven't tried to implement re-starting. I'm currently thinking it's best to revert to Dave's original suggestion i.e. just tweak the interface. To that end, svn code has been reverted, such that WITH_SU is gone, but any commandline option '-u' highlights the statusbar username. Run with e.g.
sudo emelfm2 -u ....
OR
sh -c "pkexec emelfm2 -u ...."

I've read that pkexec by itself generally doesn't support running GUI applications as another user, and may need a custom .policy file such as Dave has used. I can't test these things here, as my pkexec remains borked - some distro problem that I haven't time to fix. gksu is better in this regard, I think.

 Bonus points if the
root app can share the normal one's config folder without
mucking it up.

Dave, I see you've figured that one out. Commandline option -c <realuser-home>/.config/emelfm2 will prevail over root's config data. I presume this could be automatically handled if we were to go the way of option 1, above.

Regards
Tom

[t***@onepost.net]

On Sat, 12 Oct 2013 10:44:24 +0000

Post by s***@yopmail.com
My main complaint is sudo/root usage. There again, the sys
interactions are the gotchas. It's not the app but how it
gets called, reads configs, etc. Other FMs run as root user
aren't so itchy.

My thoughts ATM are:

1. command line option

Re-purpose current -u option (it's practically useless, -h is enough)
-u,--user=ID
ID is name or number

2. optional plugin

Optional due to extra dependencies

WITH_POLKIT = 0

At session start, pop up a password dialog.
Use PAM to validate, change
installed file /etc/pam.d/emelfm2-session, with e.g.
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth include system-auth
account include system-auth
password include system-auth
session optional pam_xauth.so
session include system-auth

On success, reconfigure environment etc, much like su command

libpam dependency

WITH_POLKIT = 1

At session start, check for authorised already (is this possible?)
If not, get authority, persistent through session.

On success, reconfigure environment etc - needed ?

libpolkit-gobject dependency

Most of the infrastructure for the above already exists.

I need to figure out how to manipulate PAM and polkit. Maybe your org.archlinux.custom.pkexec.emelfm2.policy is one starting point. Help welcome.

Regards
Tom

Post by s***@yopmail.com
Here are my root user setup files, which come to think of,
I need to fix with the -2 switch someplace, egad.
XDG_CONFIG_VOLATILE is my own env var, not a standard XDG one.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
<action id="org.archlinux.custom.pkexec.emelfm2">
<message>Authentication is required to manage system files</message>
<icon_name>emelfm2</icon_name>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/emelfm2</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
</action>
</policyconfig>