[lttng-dev] Problem with application changing UID
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. : 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@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@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@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@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@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH lttng-tools] Fix: use newly created event filter for condition check
4c5e3185d75ffe90b04107744693964d9051fb6b introduced a regression while
fixing the filter and filter_expression ownership.
Setting the "filter" object to NULL prevents the call to
add_filter_app_ctx when needed.
We use the filter from the newly created event to
perform the check and the call to add_filter_app_ctx.
Fixes coverity #1399733
Signed-off-by: Jonathan Rajotte
---
src/bin/lttng-sessiond/event.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
index f32db4429..a8b7646da 100644
--- a/src/bin/lttng-sessiond/event.c
+++ b/src/bin/lttng-sessiond/event.c
@@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
created = 1;
}
- if (created && filter) {
- ret = add_filter_app_ctx(filter, filter_expression, agt);
+ if (created && aevent->filter) {
+ ret = add_filter_app_ctx(
+ aevent->filter, aevent->filter_expression, agt);
if (ret != LTTNG_OK) {
goto error;
}
--
2.17.1
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
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://lists.lttng.org/pipermail/lttng-dev/2019-June/029035.html 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 +, 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. : 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@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@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@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@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@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-tools] Fix: use newly created event filter for condition check
- On Sep 24, 2019, at 10:53 AM, Jonathan Rajotte
jonathan.rajotte-jul...@efficios.com wrote:
> 4c5e3185d75ffe90b04107744693964d9051fb6b introduced a regression while
> fixing the filter and filter_expression ownership.
What is this commit ? I'm having trouble finding it. Can you double-check and
provide the commit Subject as well ?
Typically:
commit 1234567890ab "Commit subject"
Thanks,
Mathieu
>
> Setting the "filter" object to NULL prevents the call to
> add_filter_app_ctx when needed.
>
> We use the filter from the newly created event to
> perform the check and the call to add_filter_app_ctx.
>
> Fixes coverity #1399733
>
> Signed-off-by: Jonathan Rajotte
> ---
> src/bin/lttng-sessiond/event.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
> index f32db4429..a8b7646da 100644
> --- a/src/bin/lttng-sessiond/event.c
> +++ b/src/bin/lttng-sessiond/event.c
> @@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
> created = 1;
> }
>
> - if (created && filter) {
> - ret = add_filter_app_ctx(filter, filter_expression, agt);
> + if (created && aevent->filter) {
> + ret = add_filter_app_ctx(
> + aevent->filter, aevent->filter_expression, agt);
> if (ret != LTTNG_OK) {
> goto error;
> }
> --
> 2.17.1
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Problem with application changing UID
On Tue, Sep 24, 2019 at 02:32:41PM +, 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. : Destroy session > * Otherwise it will be destroyed next daemon launch in step 5 When in this chain of operations is lttng-sessiond started? > > [cid:image001.png@01D56F9D.AF158770] > The logs are cleared when ‘lttng destroy sess’ is called via the LTTng C-API. > From my understanding, this should not happen. I would tend to agree with you here. Would you be able to provide a small reproducer for this? What is the version of lttng-* -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH lttng-tools v2] Fix: use newly created event filter for condition check
The following commit introduced a regression while
fixing the filter and filter_expression ownership.
commit b0a23296344e57bd2e48e62ec2d7e0d8a38661bb
Author: Jérémie Galarneau
Date: Sat Jan 12 14:53:56 2019 -0500
Fix: leak of filter bytecode and expression on agent event re-enable
The agent subsystem does not properly assume the clean-up of an
event's filter bytecode and expression when a previously disabled
event is re-enabled.
This change ensures that the ownership of both the filter bytecode
and expression is assumed by the agent subsystem and discarded
when a matching event is found.
Steps to reproduce the leak:
$ lttng create
$ lttng enable-event --python allo --filter 'a[42] == 241'
$ lttng disable-event --python allo
$ lttng enable-event --python allo --filter 'a[42] == 241'
Signed-off-by: Jérémie Galarneau
Setting the "filter" object to NULL prevents the call to
add_filter_app_ctx when needed.
We use the filter from the newly created event to
perform the check and the call to add_filter_app_ctx.
Fixes coverity #1399733
Signed-off-by: Jonathan Rajotte
---
src/bin/lttng-sessiond/agent.c | 1 +
src/bin/lttng-sessiond/event.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/bin/lttng-sessiond/agent.c b/src/bin/lttng-sessiond/agent.c
index 9ea899f57..79233ab7c 100644
--- a/src/bin/lttng-sessiond/agent.c
+++ b/src/bin/lttng-sessiond/agent.c
@@ -1145,6 +1145,7 @@ struct agent_event *agent_create_event(const char *name,
event->loglevel_type = loglevel_type;
event->filter = filter;
event->filter_expression = filter_expression;
+ event->enabled = 0;
error:
return event;
}
diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
index f32db4429..a8b7646da 100644
--- a/src/bin/lttng-sessiond/event.c
+++ b/src/bin/lttng-sessiond/event.c
@@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
created = 1;
}
- if (created && filter) {
- ret = add_filter_app_ctx(filter, filter_expression, agt);
+ if (created && aevent->filter) {
+ ret = add_filter_app_ctx(
+ aevent->filter, aevent->filter_expression, agt);
if (ret != LTTNG_OK) {
goto error;
}
--
2.17.1
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-tools] Fix: use newly created event filter for condition check
> > 4c5e3185d75ffe90b04107744693964d9051fb6b introduced a regression while > > fixing the filter and filter_expression ownership. > > What is this commit ? I'm having trouble finding it. Can you double-check and > provide the commit Subject as well ? Seems like I copied the parent tree commit. See v2 Cheers ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-tools v2] Fix: use newly created event filter for condition check
Do not review, this include a change that should not be part of this commit.
On Tue, Sep 24, 2019 at 11:21:14AM -0400, Jonathan Rajotte wrote:
> The following commit introduced a regression while
> fixing the filter and filter_expression ownership.
>
> commit b0a23296344e57bd2e48e62ec2d7e0d8a38661bb
> Author: Jérémie Galarneau
> Date: Sat Jan 12 14:53:56 2019 -0500
>
> Fix: leak of filter bytecode and expression on agent event re-enable
>
> The agent subsystem does not properly assume the clean-up of an
> event's filter bytecode and expression when a previously disabled
> event is re-enabled.
>
> This change ensures that the ownership of both the filter bytecode
> and expression is assumed by the agent subsystem and discarded
> when a matching event is found.
>
> Steps to reproduce the leak:
> $ lttng create
> $ lttng enable-event --python allo --filter 'a[42] == 241'
> $ lttng disable-event --python allo
> $ lttng enable-event --python allo --filter 'a[42] == 241'
>
> Signed-off-by: Jérémie Galarneau
>
> Setting the "filter" object to NULL prevents the call to
> add_filter_app_ctx when needed.
>
> We use the filter from the newly created event to
> perform the check and the call to add_filter_app_ctx.
>
> Fixes coverity #1399733
>
> Signed-off-by: Jonathan Rajotte
> ---
> src/bin/lttng-sessiond/agent.c | 1 +
> src/bin/lttng-sessiond/event.c | 5 +++--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/bin/lttng-sessiond/agent.c b/src/bin/lttng-sessiond/agent.c
> index 9ea899f57..79233ab7c 100644
> --- a/src/bin/lttng-sessiond/agent.c
> +++ b/src/bin/lttng-sessiond/agent.c
> @@ -1145,6 +1145,7 @@ struct agent_event *agent_create_event(const char *name,
> event->loglevel_type = loglevel_type;
> event->filter = filter;
> event->filter_expression = filter_expression;
> + event->enabled = 0;
> error:
> return event;
> }
> diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
> index f32db4429..a8b7646da 100644
> --- a/src/bin/lttng-sessiond/event.c
> +++ b/src/bin/lttng-sessiond/event.c
> @@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
> created = 1;
> }
>
> - if (created && filter) {
> - ret = add_filter_app_ctx(filter, filter_expression, agt);
> + if (created && aevent->filter) {
> + ret = add_filter_app_ctx(
> + aevent->filter, aevent->filter_expression, agt);
> if (ret != LTTNG_OK) {
> goto error;
> }
> --
> 2.17.1
>
--
Jonathan Rajotte-Julien
EfficiOS
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH lttng-tools v3] Fix: use newly created event filter for condition check
The following commit introduced a regression while
fixing the filter and filter_expression ownership.
commit b0a23296344e57bd2e48e62ec2d7e0d8a38661bb
Author: Jérémie Galarneau
Date: Sat Jan 12 14:53:56 2019 -0500
Fix: leak of filter bytecode and expression on agent event re-enable
The agent subsystem does not properly assume the clean-up of an
event's filter bytecode and expression when a previously disabled
event is re-enabled.
This change ensures that the ownership of both the filter bytecode
and expression is assumed by the agent subsystem and discarded
when a matching event is found.
Steps to reproduce the leak:
$ lttng create
$ lttng enable-event --python allo --filter 'a[42] == 241'
$ lttng disable-event --python allo
$ lttng enable-event --python allo --filter 'a[42] == 241'
Signed-off-by: Jérémie Galarneau
Setting the "filter" object to NULL prevents the call to
add_filter_app_ctx when needed.
We use the filter from the newly created event to
perform the check and the call to add_filter_app_ctx.
Fixes coverity #1399733
Signed-off-by: Jonathan Rajotte
---
src/bin/lttng-sessiond/event.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/bin/lttng-sessiond/event.c b/src/bin/lttng-sessiond/event.c
index f32db4429..a8b7646da 100644
--- a/src/bin/lttng-sessiond/event.c
+++ b/src/bin/lttng-sessiond/event.c
@@ -513,8 +513,9 @@ int event_agent_enable(struct ltt_ust_session *usess,
created = 1;
}
- if (created && filter) {
- ret = add_filter_app_ctx(filter, filter_expression, agt);
+ if (created && aevent->filter) {
+ ret = add_filter_app_ctx(
+ aevent->filter, aevent->filter_expression, agt);
if (ret != LTTNG_OK) {
goto error;
}
--
2.17.1
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID
Hi, lttng-sessiond is launched in step 1 (with adequate delay before my daemon). The versions of LTTng are from poky/sumo: * lttng-modules 2.10.9 * lttng-tools 2.9.11 * lttng-ust 2.10.3 Unfortunately, the destroy session call that clears my logs is very likely tied to the systemd service file and the changing of user ID, so reproducing is not so simple. I will have to get back to you on whether or not I can easily make a reproduceable example. Regards, Zach -Original Message- From: Jonathan Rajotte-Julien Sent: Tuesday, September 24, 2019 5:15 PM To: Kramer, Zach Cc: lttng-dev@lists.lttng.org Subject: [EXTERNAL] Re: [lttng-dev] Problem with application changing UID On Tue, Sep 24, 2019 at 02:32:41PM +, 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. : Destroy session > * Otherwise it will be destroyed next daemon launch in step 5 When in this chain of operations is lttng-sessiond started? > > [cid:image001.png@01D56F9D.AF158770] > The logs are cleared when ‘lttng destroy sess’ is called via the LTTng C-API. > From my understanding, this should not happen. I would tend to agree with you here. Would you be able to provide a small reproducer for this? What is the version of lttng-* -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
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 Sent: Tuesday, September 24, 2019 5:08 PM To: Kramer, Zach Cc: lttng-dev@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%7C0fa610945b6a4857ce0408d74100fa70%7Cc12007a4882b4381b05ab783431570c7%7C1%7C0%7C637049344808702442&sdata=mkbvRXQ9GDSDIfJlD%2BL1CVqG18TDz9kxsNgMFdMIvsI%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 +, 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. : 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@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@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@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@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@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@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID
Hi Zach, Forgot to add that you might want to look at available UST wrappers depending on the nature of your daemon application. https://lttng.org/docs/v2.10/#doc-using-lttng-ust-with-daemons https://lttng.org/docs/v2.10/#doc-liblttng-ust-fd Cheers -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID
Hi Jonathan, Thanks for the extra info. We do indeed fork without a following exec call and I experimented with this preloading recently. When I experimented, I noticed no difference in the tracing when I preload liblttng-ust-fork.so. What exactly is the consequence of not doing this? Thanks! -Original Message- From: Jonathan Rajotte-Julien Sent: Tuesday, September 24, 2019 6:06 PM To: Kramer, Zach Cc: lttng-dev@lists.lttng.org Subject: Re: [EXTERNAL] Re: [lttng-dev] Problem with application changing UID Hi Zach, Forgot to add that you might want to look at available UST wrappers depending on the nature of your daemon application. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flttng.org%2Fdocs%2Fv2.10%2F%23doc-using-lttng-ust-with-daemons&data=02%7C01%7CZach.Kramer%40cognex.com%7C5bd45c30c5bd4c48ad4c08d741091b32%7Cc12007a4882b4381b05ab783431570c7%7C1%7C0%7C637049379681260582&sdata=R8O%2Be9j9O4O7pUAX5TAmLGQLGoIRKgg5k9vOixhTDHg%3D&reserved=0 https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flttng.org%2Fdocs%2Fv2.10%2F%23doc-liblttng-ust-fd&data=02%7C01%7CZach.Kramer%40cognex.com%7C5bd45c30c5bd4c48ad4c08d741091b32%7Cc12007a4882b4381b05ab783431570c7%7C1%7C0%7C637049379681270586&sdata=iNJnFMPDqCUzZS6a2hUrN4tGfpoInT5MgQYnANk6Y4g%3D&reserved=0 Cheers -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [EXTERNAL] Re: Problem with application changing UID
On Tue, Sep 24, 2019 at 04:13:13PM +, Kramer, Zach wrote: > Hi Jonathan, > > Thanks for the extra info. We do indeed fork without a following exec call and > I experimented with this preloading recently. When I experimented, I noticed > no difference in the tracing when I preload liblttng-ust-fork.so. What exactly > is the consequence of not doing this? It mostly ensure that the state of lttng-ust for the child is valid and the child will register to lttng-sessiond. It allows the child to trace between the fork call and the exec call if any. https://github.com/lttng/lttng-ust/blob/f596de62e69d1942ec545b8ba6b8f8b7244f8fb4/liblttng-ust/lttng-ust-comm.c#L2097 So in your case you definitely need it. The immediate consequence is that some context information will be completely wrong (pid/vtid). Mathieu Desnoyers could provide more information on the deeper side effects of not using the fork wrapper given that no exec call is done. I'm not completely sure of the possible side effects on the tracing buffers. Cheers -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
