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

[Siva Velusamy <siva.velusamy@xxxxxxxxx>]

On Tue, Jun 21, 2011 at 9:47 AM, Corey Ashford <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.

/Siva

Attachment: oprofile.policy
Description: Binary data