On Thu, 31 Oct 2013 07:16:21 +0000 systemdkiosk@xxxxxxxxxxx wrote: > 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. > > 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. > > 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. > > 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 > 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. > > 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. > > 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 > 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. > And if you haven't heard of it, I recommend redshift for > general computer use. OK, thanks. 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.