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 +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@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
