0004704: Behaviour of sogo-tool and sogo-alarms-notify in version 3 - SOGo

ID	Project	Category	View Status	Date Submitted	Last Update

0004704	SOGo	Backend General	public	2019-03-19 07:05	2026-07-07 11:58

Reporter	arodier74	Assigned To
Priority	normal	Severity	major	Reproducibility	always
Status	new	Resolution	open
Platform	Linux	OS	Debian	OS Version	9.0

Summary	0004704: Behaviour of sogo-tool and sogo-alarms-notify in version 3
Description	Two tools are opening the root folder ("/") thousand times a day, just for reading and getting the attributes. This is visible with AppArmor: `operation="getattr" profile="/usr/sbin/sogo-ealarms-notify" name="/" comm="sogo-ealarms-no" requested_mask="r" fsuid=126 ouid=0 operation="getattr" profile="/usr/sbin/sogo-tool" name="/" comm="sogo-tool" requested_mask="r" fsuid=126 ouid=0 operation="open" profile="/usr/sbin/sogo-tool" name="/" comm="sogo-tool" requested_mask="r" fsuid=126 ouid=0` I really wonder why those binaries are opening the root ("/") folder, even for reading and getting the attributes. What is the point of doing this? Is this a bug? Is this fixed in the version 4?
Steps To Reproduce	Install AppArmor, and select complain mode for sogo-tool and sogo-ealarms-notify. See the logs using journalctl
Tags	No tags attached.

arodier74 2026-06-27 08:11 reporter ~0018513	Still happening with Debian Trixie 13

Christian Mack 2026-07-07 11:58 developer ~0018520	sogo-tool and sogo-alarms-notify are command line tools used in cron jobs. Therefore they get started every time those cron jobs are triggered. sogo-alarms-notify runs every minute so it has to navigate to /etc/sogo/sogo.conf 1440 times per day to read SOGo's config for finding the database. And no this is no bug, it is intended behaviour. Not sure, if and how this will change in SOGo 6, as that is still in early development.

Date Modified	Username	Field
2019-03-19 07:05	arodier74	New Issue
2026-06-27 08:11	arodier74	Note Added: 0018513
2026-07-07 11:58	Christian Mack	Note Added: 0018520