Global Settings

The Global Settings component provides a common API and storage for all applications and services to access user preferences (fonts, sizes, themes) and other application setting and configuration data. Global Settings are hierarchical and could be used, e.g., as the basis for OMA Device Management settings storage. The component is designed to support the security requirements of OMA Device Management. The storage for Global Settings uses the recently open-sourced libsqlfs project layered on SQLite. Global Settings provides generic, non-mobile specific, storage.

The Global Settings service provides functions for storing user preferences. It provides APIs for the setting and getting of software configurations (typically key-value pairs such as "font size: 12 points"). The settings keys may form a hierarchy like a directory tree, with each key comparable a file or directory in a file system. E.g. "applications/datemanager/fontsize". Indeed, Global Settings can be implemented on top of a file system. Due to file system limitations in the mobile environment we will implement it differently. But conceptually Global Settings tree follows the logic structure of an Posix file system; each key has a value and meta data such as a user id, a group id, and an access permission.

The Global Settings service has two parts: the daemon (aka server) and the client library. You could store settings by simply having a server process. However, to make it trivial for the clients to talk to the server, we also provide a client library which handles the IPC to the server. The client library is linked in with the client application.
The client library and the daemon communicate via DBUS or ALP IPC. The daemon does the actual I/O for the data; it links with the SQLite library and does the key content reads and writes on SQLite databases, with the tree hierarchy actually implemented using relational tables through SQL. SQLite provides no effective access control, so the daemon uses Unix file access control on the database file to exclude everyone else. The daemon also keeps track of the users and groups that are allowed to access certain keys, and enforces access control. The SQLite database files will be only readable and writable by the daemon process.

A prior design used GConf. To better support OMA-DM we dropped the GConf design; it does not provide security over keys.

Data Model

We expose key/value pairs where values are also called "contents" of the key and can be arbitrary data of arbitrary size.
Key descriptions (in multiple languages) are supported only by convention (see below)
We support settings that are user, group, or other readable/writable (or not); the user and group identities are based on these of the system and are granted by the system. The Global Settings service does not give special meanings to any specific group or user id.

Null Values

When a new key is created, it can have no values, or just the null value. This value has the type "INVALID" and a size of zero. This is useful for creating a key and setting the value to something later. This is also required for creating a directory—which requires to create the key for the directory entry first, as described below.

Value data types

Global Settings support the following data types for key values:

int (integers)
float (double in C)
string (zero-terminated string in UTF8)
bool (boolean values TRUE and FALSE)
blob (an binary buffer with a length)
dir (used to represent directories in the key space, which has no values itself but contains child keys)
list (a list of int, float, string or bools)\

There are specific convenience APIs for reading and writing such data types except lists.

These data types have the "canoncial type names" and they are the names in the above list. For example, "int" is the official name but "integer" is not a valid type name. The canoncial type names are used in API names, C constants and string representations of the types in the Global Settings database and the XML fields in the initial settings files in XML.

List Value Representation

Due to the complexity in creating and manipulating list values, there are no specific APIs for list values. Instead you have to create lists by yourself. Global Settings list values are to be represented in memory using the glib data structure GList, with each element represented by a GList node whose "data" member points to an AlpGlobalSettingsValue.

Note: Global Settings allows lists of lists and other constructs using lists, although you are on your own operating on such structures. Global Settings only provides the mechanisms for serializing and deserializing such data structures for storing them as key values in the Global Settings database.

Key paths

The possible key names or key strings form a key space, which is similar to the space of file paths. The key strings are also called key paths. Each key path can be absolute or relative; absolute key or key paths must start with /, and relative key paths are relative to a "current directory" or a "cwd". There are APIs to get and to set the "cwd."

"Directory" keys

A "directory" is a key which contains other keys. A directory is like the interior nodes in the OMA-DM Tree definition. To simplify our design we disallow a directory key from having its own content. So if you add a child key to an existing key which has no value (or having the null value), that key becomes a directory and attempts to set the content for that key will fail in the future. Permissions for directories will then follow the corresponding semantics in the Unix file system.
A directory key can be created in two ways:

A directory is created if a request is made to create a key that would be a child or a further descent of the directory.
Or a key can be created with an explicit API for this purpose (see below)

Default values

We use a simple mechanism for supporting default values. For a key S, we define that it has a default value if another key named S.default exists. Then an get key operation on S will return the content of S.default if the key S does not exist.

Key Conventions

Key names should follow a standard convention to allow grouping of similar attributes under the same part of the key hierarchy. We will follow the GConf conventions as closely as possible for application preferences and system settings, with consideration for device-specific standards like /dm for OMA-DM.

Some typical keys are represented below:

/dm for OMA DM
/capabilities for "is java installed", "is garnet_vm installed" etc
/packages/com.access.apps.app1 for preferences of "app1"

Data Security

The Global Settings service is not meant for storage of security-sensitive data such as passwords or private keys. The data in the Global Settings are only protected by Unix file permissions and are not encrypted or Digital Restriction Managed!

Permission Control

Global Settings implements the POSIX file permission (user, group and others, readable, writeable or executable) model on the keys and the key hierarchy. So a run time process has to acquire the appropriate user or group IDs to access a key the same way it access a file with the same POSIX permission bits in the host file system.

Otherwise, Global Settings places no meanings on the uids and gids, except the uid 0 which has permissions for everything, as root.

The SUID bit is not honored and ignored for Global Settings

The x bits in directories determine if the directories can be entered; the x bits in non-directory keys are ignored and have no meaning currently.

The uid and gids of keys are modifiable according to the following rules:

The owner id cannot be changed except by the root.
The group id cannot be changed except by the root or the owner.

Global Settings has reserved rooms for extra attributes for keys, currently not implemented but these could be used for access control lists or some other meta data but I treat such usage as the best to be avoided; if POSIX permissions provide all that's needed it is the best as it is simple and efficient.

Initial key installation

With the above convention for keys, it becomes desirable for the applications or specific device (drivers) to create its key hierarchy during the installation time (or at the point of system image creation). Once created a hierarchy may be protected from access by applications other than the designated applications.
The initial key installation follow these steps:

A group id is pre-assigned to a particular application (group). This assignment is to be guaranteed at run time by the Package Manager and system security.

After an application is installed, it, or the Package Manager, will use an Global Settings tool, gset_tool, or equivalent APIs, to copy the key data from the default settings XML file into the Global Settings database and properly set the user and the group ids and the permissions for these keys.

Later the Global Settings service ensures that the key hierarchy is accessible only to applications with the right group membership or the user id. The Unix file permission style permissions will be the only security mechanism protecting the key and key values; Global Settings does not provide encryption-based protection mechanism.

Background Activities

The Global Settings daemon will be started at system boot time. Packages will need to include their associated default preferences and these will need to be installed in the correct fashion for the underlying preferences system. This is likely to be handled by a script executed by the package manager (and/or hot sync?) after extracting the files and verifying proper permissions.

Change Notification

Clients that wish to be informed of changes in settings, can register a callback with the system's Notification Manager. The Global Settings daemon will send out to Notification Manager a string representing each key that it changes. Notification Manager will notify each app that has registered to be told about that key changing. (Notification Manager will notify each app that registered for that key, or a prefix of that key. E.g. an app that registered for "oma/apps" would be notified when any of the following keys changed: "oma/apps/calendar/fontsize", "oma/apps/date/background-image", or "oma/apps".

Following the conventions of the Notification Manager, each key change notification has the "notification type" (or "notify type") of a string of the form "/alp/globalsettings/keychange/" + the key string. For example, a change of the key "oma/apps/calendar/fontsize" will invoke an alp_notify_mgr_broadcast() call with the notification type

"/alp/globalsettings/keychange/oma/apps/calendar/fontsize"

The Notification Manager currently is responsible for monitoring the key changes in a directory tree; it implements this by checking if a changed key has, as a prefix, a substring which matches the representative key of a key subspace being monitored for changes by some application. For example, the previous key change example will invoke change notifications for applications which want to know key changes in the /oma/apps/calendar/ key directory. The Notification Manager is the actual component which checks this and invoke the notification callback in client applications.

Detailed information on Global Settings can be found here.

Back to "About Hiker... "