Re: [linuxtools-dev] The location of Linux Tools Project executables

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 06/21/2011 10:09 AM, Siva Velusamy wrote:
> 
> 
> On Tue, Jun 21, 2011 at 9:47 AM, Corey Ashford
> <cjashfor@xxxxxxxxxxxxxxxxxx <mailto:cjashfor@xxxxxxxxxxxxxxxxxx>> wrote:
> 
>     On 06/21/2011 05:54 AM, Daniel HB wrote:
> 
>         Hey Corey!
> 
>         I think it's a good idea but I don't think, unfortunately, that is
>         simple to implement in the case of the Oprofile plugin. It uses
>         a script
>         to add an entry in the sudoers (Suse) or add a security wrapper for
>         consolehelper (RHEL). After that it executes the tool using a
>         symbolic
>         link located inside its own plugin dir (under
>         /scripts/natives/linux dir
>         or something like that). Both procedures require a path to the
>         oprofile
>         binary and root access.
> 
> 
>     That's a good point that hadn't occurred to me.  I don't know enough
>     about the PolicyKit authentication system that is to be used in the
>     future, but for the old mechanism, if we are using sudoers, we
>     wouldn't need the symbolic link at all; we can just invoke the
>     executable directly.
> 
>     But you're right about the consolehelper option, that's difficult to
>     solve using the mechanism I suggested.  We'd probably need multiple
>     consolehelper links, each invoking a different opcontrol program.
> 
> 
> 
> Thanks to Jeff's suggestions, I looked at policykit for a few minutes
> (that is really about all the time I spent on it). It seems like a
> really nice solution. All I had to do was to copy 2 policy files (one
> for opcontrol, and one for opreport) into /usr/share/polkit-1/actions
> folder, and since the policy I have (see attachment) allows all users
> access to oprofile, everything else just works.
> 
> I personally think that users should be given a sample policy file, and
> then can choose to customize and install it entirely outside of Eclipse.
> That way, the oprofile plugins can completely avoid these authentication
> issues. Since my background is in embedded systems, this level of
> security is fine with me. For servers, you probably need to analyze
> whether this works for you.

Thanks for your reply, Siva :)

I think something like works fine in the case of running opcontrol on
the same machine, but it's not clear to me how you go about
authenticating when the machine running opcontrol is remotely located.

If I understand the system correctly, it seems like a different
Authentication Agent is needed, because neither the GTK- nor text-based
Authentication Agent will work for the remote case.  Either that, or we
need something equivalent to adding a name to /etc/sudoers, where no
authentication is needed so long as the logged-in user is pre-authorized.

PolicyKit does provide an abstract base class for Authentication Agents,
so perhaps we could figure out a way of exporting the pop-up dialog to
the client.

- Corey