Thanks for the analysis!

Changes have been made in Git (master):

commit 53a4e7c30c9b3df2dab4acd39fcc7f985e28a5c9
Author: Jan Schneider <jan@horde.org>
Date:   Fri Feb 19 10:08:27 2016 +0100

     Protect against stale share permissions (Bug #14259).

  framework/Share/lib/Horde/Share/Sql.php |    8 ++++++--
  framework/Share/package.xml             |    4 ++--
  2 files changed, 8 insertions(+), 4 deletions(-)

http://github.com/horde/horde/commit/53a4e7c30c9b3df2dab4acd39fcc7f985e28a5c9

Okay, I just realized my table kronolith_sharesng_users had two problems:


1 - One row had a share_id which did not existed on kronolith_sharesng 
table, but referring to a user_uid that did exist on 
kronolith_sharesng (which, in the case, was my uid: 'lfbm')

So it was really messing up the $shares variable from line 310 from 
file Horde/Share/Sql.php, since it does not verify if the share_id 
from kronolith_sharesng_users exists on kronolith_sharesng.

The outcome is $shares array ends up with one last item that only has 
perms, but not a share_id, share_name and so on.


2 - One share_id that exists (and is used by a active user) on 
kronolith_sharesng did not existed on kronolith_sharesng_users. I'm 
not sure what was the effect it was causing (if any at all).


So after adjusting number 1 above, horde-alarms has stopped 
duplicating entries with the wrong user_uid.

As for number 2, I'm not sure yet if this will have any effect.

As for why the share_id got messed up on kronolith_sharesng_users, I 
think I'll never know. Maybe it was during db migration process. Can't 
say.

Anyway, I think this is not a bug, maybe the need for an enhancement, 
if at all, in order to add some verification code to see if 
$row['share_id'] actually exist on $shares before creating another 
array element in it on line 310 from Horde/Share/Sql.php.

Thanks!

We've been discussing this on the mailing list. The root cause of this 
is an entry in either the kronolith_shares or kronolith_sharesng 
(depending on the driver in use) with an empty share_id value.

Check your table to see if you have such an entry and please let us 
know if you recognize the share, or if it's some cruft left over from 
old data...

Ok, here´s what I´ve found so far.

File: Horde/Share/Object.php

public function listUsers($perm_level = null)
{
     $perm = $this->getPermission();
     $results = array_keys($perm->getUserPermissions($perm_level));
     Horde::debug($results);
     (...)

After running horde-alarms, I get this:

I don´t know why horde-alarms triggers Horde_Share_Object::listUsers 
two times. Anyway, the second one it retrieves an empty array. PS: I 
only activate the debug function after creating the test event and 
before running horde-alarms.

Then, I changed the debug to:

public function listUsers($perm_level = null)
{
     $perm = $this->getPermission();
     $results = array_keys($perm->getUserPermissions($perm_level));
     // Always return the share's owner.
     $owner = $this->get('owner');
     if ($owner && !in_array($owner, $results)) {
         Horde::debug($owner);
         $results[] = $owner;
     }
     return $results;
}

And then it gets weird, because clearly a user which does not have 
access to that calendar (the user 'lfbm') is added to the results array:

So this is why the variable $users inside 
Kronolith_Application::listAlarms shows both 'robm' (the calendar 
owner) and 'lfbm' users. And the 'lfbm' is me, who is getting the 
notificatinos from the private 'robm' calendar.

File: kronolith/lib/Application.php

public function listAlarms($time, $user = null)
     {
         $current_user = $GLOBALS['registry']->getAuth();
         if ((empty($user) || $user != $current_user) && 
!$GLOBALS['registry']->isAdmin()) {
             throw new Horde_Exception_PermissionDenied();
         }

         $group = $GLOBALS['injector']->getInstance('Horde_Group');
         $kronolith_shares = 
$GLOBALS['injector']->getInstance('Kronolith_Shares');

         $alarm_list = array();
         $time = new Horde_Date($time);
         $calendars = is_null($user)
             ? array_keys($kronolith_shares->listAllShares())
             : $GLOBALS['calendar_manager']->get(Kronolith::DISPLAY_CALENDARS);
         $alarms = Kronolith::listAlarms($time, $calendars, true);
         foreach ($alarms as $calendar => $cal_alarms) {
             if (!$cal_alarms) {
                 continue;
             }
             try {
                 $share = $kronolith_shares->getShare($calendar);
             } catch (Exception $e) {
                 continue;
             }
             if (empty($user)) {
                 $users = $share->listUsers(Horde_Perms::READ);
                 Horde::debug($users);
                 (...)


horde_debug.txt results:

Yes, the calendar in question is private only. Please, see the 
attached screenshot of the calendar´s permission.

This debug log is from reading the alarms already entered into the 
alarms table. We need to find out why the alarm_uid of the incorrect 
user is being set. Look in Kronolith_Application::listAlarms. Pay 
attention to the code that sets the $users variable.

As an aside: Are you 100% sure the user is not a member of any group 
given read perms on that calendar?

I thought I could attach more than a file per comment. Here it goes.

I thought I could attach more than a file per comment. Here it goes.

I´ve have inserted in Horde/Alarm.php the following debug commands 
below line 116:

$alarms = $this->_list($user, $time);
Horde::debug($user);
Horde::debug($time);
Horde::debug($alarms);

Then I ran horde-alarms.php.

Then I could spot the event from another user´s private calendar being 
pulled. Please see the attached horde_debug.txt.

The problem is the event with id 'DO9fBDwIcfYXXR3jXH-yy6U' was pulled 
for display to the user 'lfbm', but actually this event belongs to a 
calendar which this user ('lfbm') does not have access to.

In the attached slq queries you can see the event 
'DO9fBDwIcfYXXR3jXH-yy6U' belongs to the calendar 'robm', which is the 
private calendar for another user (the user 'robm'). Please see the 
attached PDFs.

I hope it helps debuging the problem.

To be clear, this commit wasn't supposed to "fix" this issue, but 
rather explain why the alarm script can take longer to run now.

Kronolith is issuing event alarms from  user's private calendar to 
another user who does not have access to tha calendar. The orange 
notification box appears with the alarm title on the screen of another 
user. When clicked on event title in the orange box, then the red 
notification box appears saying "event not found".

My system already has the fixed commit from here:
https://github.com/horde/horde/commit/4b482074340bf4e7ddc469d69172c5c0a2c761f8

So probably there is something else wrong.

Jens Wahnes has confirmed this in the kronolith's mail list: