[lttng-dev] lttng enable-channel option for blocking

[Mathieu Desnoyers]

* Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> On 04/27/2012 02:43 PM, Mathieu Desnoyers wrote:
>> * Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
>>> On 04/27/2012 01:33 PM, Mathieu Desnoyers wrote:
>>>> A core difference between ulimit and user-space tracing is that ulimit
>>>> can only be set within the environment (and access right) of the user
>>>> running the application. System-wide tracing sessions can be initiated
>>>> by users member of the "tracing" group -- giving them the ability to
>>>> potentially DoS an application does not appear to me to be a good
>>>> security practice. Thoughts ?
>>> Hmm, how would that look in practice ? Lets assume there is the web
>>> server which was started by an init-script in runlevel 3. How does a
>>> user that belongs to group tracing hava a chance to DoS the already
>>> running running web server. As far as I understand the trace session
>>> concept every tracing user can only see (and affect) the tracing session
>>> that he initiated. Even if the web server itself runs in a tracing
>>> session (of user wwwrun) other tracing users wouldn't see it when they
>>> do a "lttng list", right ?
>> Let me clarify the concept of tracing session in lttng 2.0.
>>
>> We support launching per-user sessiond, which only interact with the
>> user's applications. That's all fine with security.
>>
>> Now, we also support a root system-wide sessiond, which allows kernel
>> and user-space tracing. The "tracing" group has every right to create a
>> tracing session and trace the kernel and _all_ applications that were
>> already or will be running on the system.
>
> Ah, I see. I was not aware of the "... and _all_ applications that were  
> already or will be running on the system" aspect of the concept. In that  
> case I would rather invert the semantic in the API and instead of having  
> a tracepoint() function that potentially blocks I would declare  
> tracepoint() to never ever block and additionally provide tracepointb()  
> that does potentially block.

In LTTng, we try very hard to split tracing into separate components and
to keep the number of concepts that cross components to the fewest
number possible, to make both development and end-user understanding
easier.

In this case, the question is: where should the behavior of buffer-full
scenarios should be configured ? Clearly, this is related to the tracer
ring buffer, which is usually configured through commands sent to the
lttng session daemon, and which are kept on a per-session/per-channel,
and possibly per-event basis.

Currently, the tracepoints API does not expose the tracer internals: it
only adds static instrumentation points into applications and libraries.

So keeping this in mind, one way to allow this kind of "blocking" mode
might be to add a special option to the lttng-sessiond, e.g. a
"--developer" mode, which could enable this feature, and possibly other
features that are not "safe" to deploy on production machines.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com