On Thu, 31 Oct 2013 07:16:21 +0000 systemdkiosk@xxxxxxxxxxx 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 -- Users can unsubscribe from the list by sending email to emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by logging into the web interface.