[linuxtools-dev] TCF and remote profiling/tracing

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

Hi Francois,

I'd like to start a dialog with you regarding cleaning up the TCF 
implementation for remote profiling/tracing.

The first thing I'd like to tackle is the set-up design.  I am primarily 
interested in how this can be directed from the client.  In the current 
design, remote set-up must occur via the Debug Configurations... dialog 
under TCF.

There, one can find a list of targets.  After unclicking the use-local 
options, the Add... button becomes active for the list of targets. 
Pressing this, a set of options are provided, one being the option to 
set-up an agent remotely.  Selecting this action, one gets a dialog to 
enter the root password and a separate userid/password for the remote 
system.  This kicks off a remote shell that:

1. uninstalls remote tcf-agent rpm and installs "most-appropriate"
   tcf-agent rpm for remote system
2. as part of install, runs tcf-agent to create a certificate which is
   passed back to the client and then invoked again.  A public
   certificate copy is performed by both host and remote from each
   other.
3. starts the TCF agent as a root daemon

There is a bug in the code whereby the certificate names set up are not 
in sync with the code that ultimately uses them (i.e. Local.cert vs 
local.cert).

Once the remote shell is done, manual set-up of the agent via 
environment variables is still required which is very annoying.

Here's how I would like to change the mechanism.

1. Copy the TCF set-up into Profiling Configurations... The TCF Targets 
page could be pushed into the framework so each tool could reuse it.

2. I would like to cease the shipping of the rpm over to the remote 
system.  Instead, I would like to create a new Fedora/RHEL package 
containing our TCF agent(s).  That way it can be installed from the 
remote side using the normal mechanisms.  This prevents the client from 
having to store rpms for all supported systems and platforms.  We can 
maintain the package for Fedora/RHEL.

User's on other systems can pressure their maintainers to add the 
package or they can start the agent manually and do the manual 
specification using the environment variables as they can today.

3. The current certificate system needs fixing.  Currently, a 
certificate pair gets generated when the rpm is installed which is every 
time this remote set-up is called.  The files are put in 
/etc/tcf/ssl/local.cert and /etc/tcf/ssl/local.priv.  On the client 
side, if the files don't already exist in the state location of the 
plug-in, they are copied over to the client and remotely the tcf agent 
is asked to regenerate the certificate again.  There is then a swap of 
the public certificates which are copied to both sides to have the 
respective host names where they originated.  Each side has a matched 
pair of "local.cert" and "local.priv" and each side has the other's 
local.cert renamed to be "{hostname}.cert".

One problem is that the TCFSecurityManager run on the client side has 
hardcoded the names "Local.cert" and "Local.priv" for the public and 
private key methods.  An alias name is passed in as a parameter, but the 
methods ignore it.  The hard-coded names don't even match up with the 
files originally swapped by the set-up wizard as they use "local" 
instead of "Local" (I got around this simply by renaming).  For multiple 
clients using the same target, I think it will work because the system 
chooses to copy over the public keys on both sides.  Each client will 
try to do the set-up (unless it knows the target is already running and 
the client wishes to set up the magic environment variables).  This 
means a new certificate gets regenerated each time.  Old clients won't 
have a valid public certificate that matches the remote target private 
key anymore, but that doesn't appear to matter.  In channel_tcp.c there 
is a function called certificate_verify_callback() which is set up for 
verification.  It compares the current certificate to each one ending in 
.cert in the TCF certificates directory.  There does not appear to be a 
check for the private key matching the public one.

I do see an issue with multiple Eclipse sessions from the same host. 
The problem is that currently the certificates are stored in the state 
location (per workspace).  If not already set, the tcf agent is asked to 
regenerate.  The problem is that the remote target will end up copying 
this new public certificate using the host name of the client.  This 
will trash any previous set-up that was performed from another workspace 
on the same client.  The answer to me would be to use the user location 
and to encode the username into the certificate name.  Perhaps you can 
some other thoughts on this.

4. The tcf agent requires port 1534 to be open.  The current set-up 
doesn't ensure this.  I think that it should take care of this.

5. The tcf agent runs as a root daemon.  This is dangerous since the tcf 
agent has capability of doing just about anything (starting processes, 
moving files around).  Does Lttng require root access?  Valgrind does 
not, but OProfile for instance, does.  I have recently worked on setting 
up policy kit to run /usr/bin/opcontrol (using pkexec and having a 
policy file).  Now comes the tricky part.  One sets policy based on 
whether it is the active session, an inactive session, or "any". 
AFAICT, using ssh requires "any" access.  Policy kit can be set up to 
allow, deny, or to require self authorization or admin authorization. 
It will challenge when needed, but I don't know what happens if we are 
using it remotely via Eclipse (i.e. how it will challenge and whether we 
can respond to that challenge).

Ideally, I would like to set up the agent using root access, but to 
start it under a specified user's account.  Any root access would be 
done via pkexec() and policy set up, preferably with no challenge 
required following the remote set-up which does query for a userid, 
password, and root password.  It would make sense for the root access 
issues to be tcf agent commands so that the client doesn't have to 
prefix them with pkexec.

6. Once set-up, create the target with environment variables set-up so 
the remote target just shows up in any Target list.


Anything I missed?  Thoughts?

-- Jeff J.