--- /dev/null
+This document lists bugs and limitations currently known in dump_systemstate.
+
+buxton-wait
+===========
+
+Gathering buxton (also known as vconf) database can happen in either direct
+or indirect method as described below:
+
+ - indirect method means data is gathered from buxton2 service and is
+ used by default when service is available
+
+ - direct method means that buxton2ctl accesses buxton sqlite database
+ directly - this method is used automatically by tools when buxton
+ service is not available
+
+Unfortunately, when direct method is used as fallback (eg. during
+early boot) it causes buxton database to break as described in
+following scenario:
+
+1. crash happens
+
+2. crash-manager is executed via kernel's kernel.core_pattern sysctl
+ setting
+
+3. crash-manager drops privileges * changes gid and uid to
+ crash_worker:crash_worker * drops all capabilities keeping only 4
+ caps (including cap_dac_override)
+
+4. crash-manager executes various processes: * minicoredumper etc. to
+ grab core, potentialy in minimized form * processes to dump logs -
+ mainly dump_systemstate
+
+5. dump_systemstate executes various programs as configured in
+ /etc/dumpsystate* configuration files
+
+* one of the processes executed is buxton2ctl which dumps buxton2ctl
+
+* if buxton2 service is running, then indirect method is used and
+ there is no problem
+
+Unfortunately, if buxton2 service is not running following occur:
+
+* buxton databases are normally readable only by buxton user, the db
+ in /var/lib/buxton2 is rwx------ buxton:buxton
+
+* normally the database would not be readable because processes run by
+ dump_systemstate and buxton2ctl are run with crash_worker uid:gid,
+ BUT process also have cap_dac_override capability inherited which
+ overrides DAC rights
+
+* consequently, buxton2ctl can access the database (unix permissions
+ (DAC) are ignored due to caps)
+
+* unfortunately, the database is sqlite database and sqlite internally
+ always creates joural files: /var/lib/buxton2/system.db (always
+ exists) /var/lib/buxton2/system.db-wal (created by crash_worker)
+ /var/lib/buxton2/system.db-shm (created by crash_worker)
+
+* normally when root user access the db it does change ownership to
+ the owner of original file, but crash_worker does not have this
+ permission so we end up with following:
+
+ root:~> ls -l /var/lib/buxton2/
+ total 48
+ -rw-r--r-- 1 buxton buxton 16384 Jan 1 1970 system.db
+ -rw-r--r-- 1 crash_worker crash_worker 32768 Dec 8 18:43 system.db-shm
+ -rw-r--r-- 1 crash_worker crash_worker 0 Jan 1 1970 system.db-wal
+
+Consequently, next processes that run (including buxton2d service) can
+not access and work on its databases. This causes numerous problems
+including lack of sdb access (this is because state is kept and
+communicated by vconf/buxton db).
+
+To avoid this problem we only use indirect method via the means of
+buxton-wait helper script.
--- /dev/null
+#!/bin/sh
+
+# Helper program to ensure buxton databases are already opened
+#
+# This program is needed because buxton2ctl as launched via dump_systemstate,
+# via crash-manager, has high enough permissions to create sqlite journal files
+# in /var/lib/buxton2. (The files are created internally via libsqlite logic and
+# client has no control over it).
+#
+# By waiting for buxton2 service to start we want to ensure the needed sqlite
+# files are already created with correct permissions.
+
+
+WAIT_SEC=30
+BUXTON_SERVICE=buxton2.service
+BUXTON_BIN=/usr/bin/buxton2ctl
+
+for i in $(seq 1 $WAIT_SEC); do
+ if systemctl is-active "$BUXTON_SERVICE"; then
+ exec $BUXTON_BIN "$@"
+ break
+ fi
+ sleep 1
+done
+
+exit 0
projects / platform / core / system / crash-worker.git / commitdiff