Fix: sessiond: size-based kernel rotation doesn't trigger

Fix: sessiond: size-based kernel rotation doesn't trigger

Issue observed
--------------

When a non-root user (part of the tracing group) creates a session (with kernel
domain recording channels) and sets a size-based rotation schedule, the session
daemon never performs the rotation.

Cause
-----

Size-based rotations are implemented using an internal trigger which uses a
consumed_size condition to send a notification to the session daemon.

The sessiond daemon logs indicate the following when the size threshold is crossed:

  DBG1 - 11:20:48.469994848 [Notification]: Session consumed size condition being evaluated: threshold = 1073741824, current size = 1059061760 (in evaluate_session_consumed_size_condition() at notification-thread-events.cpp:939)
  DBG1 - 11:20:48.470006990 [Notification]: Session consumed size condition being evaluated: threshold = 1073741824, current size = 1074790400 (in evaluate_session_consumed_size_condition() at notification-thread-events.cpp:939)
  DBG1 - 11:20:48.470034565 [Notification]: Enqueued action for trigger: trigger name = `(anonymous)`, work item id = 0 (in action_executor_enqueue_trigger() at action-executor.cpp:963)
  DBG1 - 11:20:48.470058161 [Notification]: Handling channel sample for channel channel0 (key = 1) in session kernel-benchmark-trace (highest usage = 1062205, lowest usage = 206058, consumed since last sample = 15728640) (in handle_notification_thread_channel_sample() at notification-thread-events.cpp:4930)
  DBG1 - 11:20:48.470069331 [Notification]: Entering poll wait (in thread_notification() at notification-thread.cpp:630)
  DBG1 - 11:20:48.470090340 [Action Executor]: Woke-up from wait (in action_executor_thread() at action-executor.cpp:754)
  DBG1 - 11:20:48.470100937 [Action Executor]: Starting execution of action work item 0 of trigger `(anonymous)` (in action_work_item_execute() at action-executor.cpp:701)
  DBG1 - 11:20:48.470111208 [Action Executor]: Policy every N = 1: execution accepted. Execution count: 1 (in lttng_rate_policy_every_n_should_execute() at actions/rate-policy.cpp:526)
  DBG1 - 11:20:48.470120044 [Action Executor]: Executing action `NOTIFY` of trigger `(anonymous)` action work item 0 (in action_executor_generic_handler() at action-executor.cpp:686)
  DBG1 - 11:20:48.470162012 [Action Executor]: Serializing session consumed size condition (in lttng_condition_session_consumed_size_serialize() at conditions/session-consumed-size.cpp:75)
  DBG1 - 11:20:48.470171532 [Action Executor]: Serializing notify action (in lttng_action_notify_serialize() at actions/notify.cpp:52)
  DBG1 - 11:20:48.470180192 [Action Executor]: Serializing notify action rate policy (in lttng_action_notify_serialize() at actions/notify.cpp:55)
  DBG1 - 11:20:48.470189784 [Action Executor]: Skipping client at it does not have the permission to receive notification for this trigger (in notification_client_list_send_evaluation() at notification-thread-events.cpp:4477)
  DBG1 - 11:20:48.470198680 [Action Executor]: Completed execution of action work item 0 of trigger `(anonymous)` (in action_work_item_execute() at action-executor.cpp:717)
  DBG1 - 11:20:48.470207436 [Action Executor]: No work items enqueued, entering wait (in action_executor_thread() at action-executor.cpp:752)
  DBG1 - 11:20:49.469998782 [Notification]: Poll wait returned (1) (in thread_notification() at notification-thread.cpp:632)

The "Skipping client at it does not have the permission to receive notification
for this trigger" hints at an invalid permission check.

Indeed, notification_client_list_send_evaluation() checks that the notification
client (on the other end of the notification channel) has the same UID as the
session on behalf of which the notification is emitted.

In this case, it is not the case. The session was created on behalf of user 1000
(part of the tracing group) while the notification client is root (uid = 0, the
session daemon performing kernel tracing).

Solution
--------

Allow notifications to go through when they target the root user.

Known drawbacks
---------------

None.

Change-Id: If66ab09523b41634e3118d6347ec500d15c70e53
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>