Hello!

I just wanted to give my view what oprofile can do more than ps. Even
thought that requires large amount of CPU time & very good source code
knowledge about program that someone else is running.

Basically you can put oprofile to collect data with very high
frequency including callgraph. Then you have a tool reading all the
data on the fly to track down the excecution of a given program. But I
think there is a lot easier techniques (and less noticeable) if one
already has root access.

I want also point that opcontrol --stop is enough to stop data
collection. So just loading oprofile kernel modules and running the
daemon doesn't expose profiling data to /var/lib. But I still would
like that /var/lib/oprofile/ wouldn't be world readable and ownership
would oprofile:adm. That should be possible if oprofiled was made to
use special user account. This could be archived with fairly simple
patch to oprofiled that would jut call setuid and umask. This would
cause all collect data automatically have correct permissions. (Unless
root changes the the oprofile user accout somehow). Of course largest
work would be testing and changes to package installation that handles
the permission settings for user account. This at least would give
some feeling of security for paranoid people.

But of course world readable profile data might be considered as a
feature. One good example could be that root is running automatic test
suit in a development project. All test data is profiled to help any
developer collect information for optimisation. This data later should
be readable by all project members (who often shouldn't have root
access to system) Everything is trade of unless someone makes this
easily configurable too.

Pauli



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to