The proposal here is to specify a naming scheme for permissions
that allows the system to be as stateless as possible.
The current specification includes in the naming of permissions either the name of the bound binding when existing and the level of the permission itself.
Doing this, there is no real need for the framework to keep installed permissions in a database.
The permission names are URN of the form:
where “AGL” is the NID (the namespace identifier) dedicated to AGL.
(note: a RFC should be produced to standardize this name space)
The permission names are made of NSS (the namespace specific string)
starting with “permission:” and followed by colon separated
The 2 first fields are
<level> and the remaining
fields are grouped to form the
<api> ::= [ <pname> ] <pname> ::= 1*<pchars> <pchars> ::= <upper> | <lower> | <number> | <extra> <extra> ::= "-" | "." | "_" | "@"
<api> can be made of any valid character for NSS except
the characters colon and star (:*).
This field designates the api providing the permission.
This scheme is used to deduce binding requirements from permission requirements.
<api> can be the empty string when the permission
is defined by the system itself.
[PROPOSAL 1] The field
<api> if starting with the character “@” represents
a transversal/cross permission not bound to any binding.
[PROPOSAL 2]The field
<api> if starting with the 2 characters “@@”
in addition to a permission not bound to any binding, represents a
permission that must be set at installation and that can not be
<level> ::= 1*<lower>
<level> is made only of letters in lower case.
<level> can only take some predefined values:
<hierarchical-name> is made of
<hierarchical-name> ::= <pname> 0*(":" <pname>)
The names at left are hierarchically grouping the
names at right.
This hierarchical behaviour is intended to be used to request permissions using hierarchical grouping.
In some case, it could be worth to add a value to a permission.
Currently, the framework allows it for permissions linked to
But this not currently used.
Conversely, permissions linked to cynagora can’t carry data except in their name.
Thus to have a simple and cleaner model, it is better to forbid attachment of value to permission.
Example of permissions
Here is a list of some possible permissions.
These permissions are available the 21th of May 2019.
Set OOMScoreAdjust=-500 to keep the out-of-memory killer away.
Set IOSchedulingClass=realtime to give to the process realtime scheduling.
Conversely, not having this permission set RestrictRealtime=on to forbid realtime features.
Adds the group “display” to the list of supplementary groups of the process.
Without this permission SystemCallFilter=~@clock is set to forfid call to clock.
The http directory served is not “htdocs” but “.”
Allows to read data of installed applications (and to access icons).
Forbids services to provide its API through websocket.
Forbids services to provide its API through D-Bus.
Starts automatically the application. Example: home-screen.
- urn:AGL:permission::partner:scope-platform Install the service at the scope of the platform.
- urn:AGL:permission::system:capability:keep-all Keep all capabilities for the service. Note that implementing that permission is not mandatory or can be adapted for the given system.
http://tizen.org/privilege/internal/dbusPermission to use D-Bus.