[lttng-dev] [EXTERNAL] Re: Problem with application changing UID

Fri Sep 27 10:07:29 EDT 2019

Hi,

Following up on this.

Unfortunately I was not able to test the patch because our build system relies on using the lttng version provided by poky -- updating is not something we can easily do.

I seemingly solved this problem in another manner, though. I built the tracepoint provider package into a shared object and dlopen() it after the root privileges have been dropped. This seems to have solved the UID problem, because the app only registers itself under the UID that it will trace under.

This resulted in another problem, which is that the metadata does not exist until the session is stopped, and once the session is started again it is no longer tracing. In the lttng documentation I found:

"Important: You need to stop tracing to make LTTng flush the remaining trace data and make the trace readable."

I interpreted this as "the metadata will not exist until the session is stopped." Is this correct?

Regardless, I enabled the channel 'metadata' and configured it to flush via the switch timer, which then gives my traces metadata.

My problem thus is seemingly solved. Do you see any flaws on the lttng side of this approach?

Best,
Zach

-----Original Message-----
From: lttng-dev <lttng-dev-bounces at lists.lttng.org> On Behalf Of Kramer, Zach
Sent: Tuesday, September 24, 2019 6:01 PM
To: Jonathan Rajotte-Julien <jonathan.rajotte-julien at efficios.com>
Cc: lttng-dev at lists.lttng.org
Subject: Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID

Hi,

Thanks for the quick response! This looks interesting -- I will experiment with it and come back with any results.

Cheers,
Zach

-----Original Message-----
From: Jonathan Rajotte-Julien <jonathan.rajotte-julien at efficios.com>
Sent: Tuesday, September 24, 2019 5:08 PM
To: Kramer, Zach <Zach.Kramer at cognex.com>
Cc: lttng-dev at lists.lttng.org
Subject: [EXTERNAL] Re: [lttng-dev] Problem with application changing UID

Hi Zach,

Thanks for reaching out.

lttng-ust does not support the change of uid once the application is registered to the lttng-sessiond daemon. I think that we use the uid received on registration for all subsequent operations.

Gabriel Pollo-Guilbert actually worked on this this summer. You can check out the proposed wrapper for setuid here [1]. You will need to LD_PRELOAD it on the start of you application. It basically unregister the application and re-register it.

[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lttng.org%2Fpipermail%2Flttng-dev%2F2019-June%2F029035.html&data=02%7C01%7Czach.kramer%40cognex.com%7C515e8022a83848c7e97f08d741086bce%7Cc12007a4882b4381b05ab783431570c7%7C1%7C0%7C637049376731748051&sdata=XXMusNtcLMynO8QhHU220Plq06P7qvrhenIFBFcTu0A%3D&reserved=0
 This should be applied on master of lttng-ust.
 Make sure to use lttng-tools master also. Same for lttng-modules if necessary.

Would you be interested in giving it a try?

Cheers

On Tue, Sep 24, 2019 at 02:32:41PM +0000, Kramer, Zach wrote:
> Hi,
>
> Is LTTng intended to support userspace applications that change their UID at run-time? As in, is there an expected behavior for when this happens?
>
> For example:
>
>   1.  Embedded device boots
>   2.  My daemon is launched as root via systemd
>   3.  Runs privileged code
>   4.  Changes UID to a less privileged user (500)
>   5.  Creates LTTng session
>      *   If session already exists, destroy it first
>   6.  <if ‘systemctl stop’ is called>: Destroy session
>      *   Otherwise it will be destroyed next daemon launch in step 5
>
> This causes many conflicts with the trace folders that are created. Most of the time, LTTng creates a folder + metadata for both root and the user, then puts traces in the user folder. Other times, it may create a folder just for the user. This is seemingly random, since it’s a fresh device boot each time. If the daemon is launched directly (i.e. not from systemd), then the root folder gets the traces and the user folder gets the metadata. Here is a more detailed explanation:
>
>
> Case
> Command
> Result
>
> Comments
> 1
> [Device boot]
> systemctl start daemon
> …../uid/500/32-bit --> has metadata and trace logs
>
> Most times, this also happens:
> …../uid/0/32-bit --> has metadata but no trace logs
>
> [cid:image001.png at 01D56F9D.AF158770]
> Occasionally, the uid/0 folder is not created at all. This seems random, since this is tested by rebooting the device several times.
> 2
> [Device boot]
> systemctl start daemon
> systemctl stop daemon
>
>   *   This uses LTTng C-API to destroy session
> …../uid/500/32-bit --> has metadata but the logs were cleared
>
> Most times, this also happens:
> …../uid/0/32-bit --> has metadata but no trace logs
>
> [cid:image001.png at 01D56F9D.AF158770]
> The logs are cleared when ‘lttng destroy sess’ is called via the LTTng C-API. From my understanding, this should not happen.
>
> Destroying the daemon from command line behaves properly. From my understanding, this should be practically the exact same command.
> 3
> root at device: daemon
>
> (launching via command-line)
> When daemon is killed or session is stopped: mimics case 1
>
> When daemon is alive:
> …./uid/0/32-bit --> has trace logs but empty metadata
>
> …./uid/500/32-bit --> has metadata but empty trace logs 
> [cid:image002.png at 01D56F9D.AF158770]
>
>
> Is this use-case supported?
>
> Unfortunately, the logs are huge and contain sensitive information. If they can help a substantial amount, I can prune them.
>
> Thanks and best regards,
> Zach

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.lttng.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flttng-dev&data=02%7C0
> 1%7CZach.Kramer%40cognex.com%7C0fa610945b6a4857ce0408d74100fa70%7Cc120
> 07a4882b4381b05ab783431570c7%7C1%7C0%7C637049344808702442&sdata=mA
> uYCBhxqSdNuYSecmk4FmlaujH8yEX7HGEi0Ysw4ko%3D&reserved=0

--
Jonathan Rajotte-Julien
EfficiOS
_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lttng.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flttng-dev&data=02%7C01%7Czach.kramer%40cognex.com%7C515e8022a83848c7e97f08d741086bce%7Cc12007a4882b4381b05ab783431570c7%7C1%7C0%7C637049376731758042&sdata=m2f45UtNBgI2PPF%2BqKxOlSokbZnTyYDfAJeULiAFhv4%3D&reserved=0