This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thoughts Systemtap plugin for Eclipse


Hi Will,
1) Need to have sshd running on target machine and allow ssh. (minor)

2) The plugin stores the user ssh/scp password as plan text. (major)
This file is world readable:
~/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.ibm.systemtapgui.generic.consolelog.prefs
Thanks for reviewing. The above two issues can be resolved, will look into it.
3) The plugin does syntax checking on the system eclipse is running
on. However, the system that server is running may be different.
It is possible the script might check okay on plugin but not run
on server due to those differences.
To solve this we would either need to eliminate syntax checking(or do only very basic checking) or be able to access the systemtap
running on the server. We have the same problem with the probes and function display.
If the systemtap version is different on the client and server, the probes shown in the GUI client may vary
with the server. We were planning to implement remote server browsing to solve this problem, so that the tapsets
on the remote system can be parsed to display the correct probe view. Am not sure how the syntax checking
problem can be addressed. Any ideas?.
4) The systemtapgui-server may allow other processes to connect up
and run things on the target machine. Could be exploited for
attacks on machine running systemtapgui-server.

The server was designed to be able to run any script(not just systemtap) and
hence the execStap() function has cases for shell scripts and BlueDye commands. This part of the code is there for future expansion.
Currently this code path is never reached and so there is no chance of arbitrary
commands being run.


Rethinking how the plugin and systemtap works. A couple possible use
cases for this functionality are:

1) Same person running everything on one machine to make use of the
   graphing and eclipse environment.

2) Person developing on one machine which has everything on it
   (systemtap, debuginfo, kernel-devel...) and sending the resulting
   instrumentation module to a stripped down machine.

The sysetmtapgui-server currently does the following:

-process management on remote machine
-build the instrumentation
-executes script
-collect stdout/stderr

The systemtap compile server does a portion of the work that the
systemtapguiserver does. However, the systemtap compile server doesn't
run the resulting script or send the output to a remote machine. The
thought would be to minimize systemtapgui-server, so it only reports
the kernel being used (so compile server can build appropriate
instrumentation for target) and runs prebuilt modules with
staprun. Have this instrumentation server in the the systemtap source and
package it like the systemtap compile server and client.
I' m not very comfortable with the idea of packaging the server with systemtap due to possible maintenance/legal issues.
SystemtapGui is currently release under EPL and moreover we will be including the GUI
in the Linux Tools eclipse project. We have been thinking about using the compile-server for
compilation so the systemtapgui server can be run on stripped-down machines, but not as a hard-dependency.


Can we treat these issues/discussions as upstream issues so that the fedora review request is not blocked?.

Regards,
Anithra.

-Will


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]