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

[Mathieu Desnoyers]

* Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> On 04/30/2012 04:20 PM, Mathieu Desnoyers wrote:
>> * 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.
>> 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.
>
> Sounds good. Our need for blocking channels is only during development  
> phase.
>
> In case of blocking it would be useful to emit a meta-event to indicate  
> that blocking happened. This allows to (optionally) factor out blocking  
> periods from event data visualizations.

We already have start-end timestamps in packet headers. We can already
compute blocking time by looking at the delta between consecutive
packet's end time and start time.

>
> Thanks,
> Paul
>
> PS: A more general question: In the light of the upcoming event  
> streaming support for LTTng, is it intended to use lttng for "regular"  
> event based real-time communication (non-tracing/debugging related) as  
> well. From that perspective, support for blocking (reliably emitted  
> events) would become mandatory (there might be events of kind  
> cooling_system_deactivated, containment_leakage_detected, ...).

Well, currently lttng-tools is designed so that even if the consumerd is
killed, the application traced with UST will continue running without
any issue. Adding the option to "block" the application would require us
to enhance the lttng-tools design in ways that would allow applications
to continue behaving correctly in case of a sessiond/consumerd failure.
That's the tricky part.

Thanks,

Mathieu

>
>>
>> Thoughts ?
>>
>> Thanks,
>>
>> Mathieu
>>
>
>
> -- 
> Paul Woegerer | SW Development Engineer
> Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria
> P 43.1.535991320
> Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS
>
> Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
> Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
>

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com