[lttng-dev] Is lttng namespace-ready?

[Thibault, Daniel]

Date: Mon, 8 Jul 2013 12:33:41 -0400
From: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>

> * Thibault, Daniel (Daniel.Thibault at drdc-rddc.gc.ca) wrote:
> >    But what of per-UID traces?  What happens to a trace in progress if
> >    one or more processes switch user namespaces?
>
> nothing.
>
> >  Presumably new
> >    sub-directories would be created under "session-name/ust/uid/"?
>
> no.

   Back on 26 Jun 2013, you said:

> Subject: Re: [lttng-dev] [RELEASE] LTTng Tools 2.2.0 - Cuda (STABLE)
> Message-ID: <20130626211926.GC4725 at Krystal>
...
> > I also presume the uid used [in the path (e.g. $HOME/lttng-traces/session-20130611-1223344/ust/uid/1000/64-bit)] is the real uid (ruid)?
>
> yes, this is correct. The one returned by getuid().

   This getuid() call occurs from the tracepoint provider attached to the instrumented application, right?  If user namespaces are in use, this will therefore be the virtual uid, and if a process is cloned() into a new user namespace it will thus tell the daemons that its events are issuing from that virtual uid.  If it is a heretofore unknown uid, a new subdirectory should thus appear under /ust/uid.  If it is an already known uid (more precisely, an already-encountered numerical value), its events should just flow into the existing channel files.  There is (I suspect) no risk of trace files being overwritten accidentally.

   The difficulty lies at the analysis end, if the user wants to sort out event streams that issue from the same numerical virtual uids but that are actually different (issuing from different real uids or from different user namespaces).  One could figure it out manually by capturing namespace API events (clone(), unshared() and setns()), but it would be nicer if lttng's metadata held this information or if lttv did it for us, wouldn't it?  Maybe the namespace identifiers could be added as context using enable-event?

   Another question that occurs to me as I write this is: will a given real uid's lttng-consumerd daemon service the processes belonging to this uid and its subordinate user namespaces, or will each new user namespace spawn a new lttng-consumerd daemon?  Is the answer the same in the per-pid and per-uid cases?

> >    What about the case where two processes run by two different users (and thus being recorded under different uid subdirectories) switch
> >    to private user namespaces which happen to both map to the same numerical virtual uid?  We need to make sure the second process
> >    switch does not overwrite the trace files of the first (recall that per-uid trace paths do not include timestamps like per-pid trace
> >    paths do).
>
> Disambiguation between different PIDs requires the vpid context if you use per-UID buffers.

   As a user, I'd probably be better off using the pid (real pid) context.  It would disambiguate between unrelated processes bearing the same vpids.

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>