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

[Woegerer, Paul]

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.

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, ...).

>
> 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.