[lttng-dev] Problem with application changing UID

[Kramer, Zach]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190924/867149e7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3141 bytes
Desc: image003.png
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190924/867149e7/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 6313 bytes
Desc: image004.png
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190924/867149e7/attachment-0003.png>