7 The proposal here is to specify a naming scheme for permissions
8 that allows the system to be as stateless as possible.
9 The current specification includes in the naming of permissions either
10 the name of the bound binding when existing and the level of the
12 Doing this, there is no real need for the
13 framework to keep installed permissions in a database.
15 The permission names are [URN][URN] of the form:
18 urn:AGL:permission:<api>:<level>:<hierarchical-name>
21 where "AGL" is the NID (the namespace identifier) dedicated to AGL.
22 (note: a RFC should be produced to standardize this name space)
24 The permission names are made of NSS (the namespace specific string)
25 starting with "permission:" and followed by colon separated
27 The 2 first fields are `<api>` and `<level>` and the remaining
28 fields are grouped to form the `<hierarchical-name>`.
33 <pname> ::= 1*<pchars>
35 <pchars> ::= <upper> | <lower> | <number> | <extra>
37 <extra> ::= "-" | "." | "_" | "@"
40 The field `<api>` can be made of any valid character for NSS except
41 the characters colon and star (:*).
42 This field designates the api providing the permission.
43 This scheme is used to deduce binding requirements
44 from permission requirements.
45 The field `<api>` can be the empty string when the permission
46 is defined by the AGL system itself.
48 [PROPOSAL 1] The field `<api>` if starting with the character "@" represents
49 a transversal/cross permission not bound to any binding.
51 [PROPOSAL 2]The field `<api>` if starting with the 2 characters "@@"
52 in addition to a permission not bound to any binding, represents a
53 permission that must be set at installation and that can not be
58 The field `<level>` is made only of letters in lower case.
59 The field `<level>` can only take some predefined values:
68 The field `<hierarchical-name>` is made of `<pname>` separated
71 <hierarchical-name> ::= <pname> 0*(":" <pname>)
73 The names at left are hierarchically grouping the
75 This hierarchical behaviour is intended to
76 be used to request permissions using hierarchical grouping.
80 In some case, it could be worth to add a value to a permission.
82 Currently, the framework allows it for permissions linked to
84 But this not currently used.
86 Conversely, permissions linked to cynara can't carry data
89 Thus to have a simple and cleaner model, it is better to forbid
90 attachment of value to permission.
92 ## Example of permissions
94 Here is a list of some possible permissions.
95 These permissions are available the 21th of May 2019.
97 - urn:AGL:permission::platform:no-oom
98 Set OOMScoreAdjust=-500 to keep the out-of-memory
100 - urn:AGL:permission::partner:real-time
101 Set IOSchedulingClass=realtime to give to the process
103 Conversely, not having this permission set RestrictRealtime=on
104 to forbid realtime features.
105 - urn:AGL:permission::public:display
106 Adds the group "display" to the list of supplementary groups
108 - urn:AGL:permission::public:syscall:clock
109 Without this permission SystemCallFilter=~@clock is set to
110 forfid call to clock.
111 - urn:AGL:permission::public:no-htdocs
112 The http directory served is not "htdocs" but "."
113 - urn:AGL:permission::public:applications:read
114 Allows to read data of installed applications (and to
116 - urn:AGL:permission::partner:service:no-ws
117 Forbids services to provide its API through websocket.
118 - urn:AGL:permission::partner:service:no-dbus
119 Forbids services to provide its API through D-Bus.
120 - urn:AGL:permission::system:run-by-default
121 Starts automatically the application. Example: home-screen.
122 - urn:AGL:permission::partner:scope-platform
123 Install the service at the scope of the platform.
124 - urn:AGL:permission::system:capability:keep-all
125 Keep all capabilities for the service. Note that implementing
126 that permission is not mandatory or can be adapted for the given
128 - <http://tizen.org/privilege/internal/dbus>
129 Permission to use D-Bus.
131 [URN]: https://tools.ietf.org/rfc/rfc2141.txt "RFC 2141: URN Syntax"