By default, a sandboxed app only has access to a configuration tree that has the same name as the app itself. Furthermore, when setting permissions in the “configTree:” section of the .adef file, the dot (.) refers to that tree, not the “system” tree.
This was done for security reasons:
- Different sandboxed apps can’t clobber or even snoop on each others’ configuration data.
- Sandboxed apps can’t snoop or change the critical system configuration data that’s in the “system” tree.
- Sandboxed apps can’t prevent other apps from writing to their configuration trees by starting write transactions on their trees.
Also, when an unsandboxed app starts a config tree transaction without specifying which tree it wants to access, then it will get a transaction on the tree that has the same name as the app.
An unsandboxed app has access to all trees, and by default gets a transaction on the “system” tree.
To give your app read-only access to the system config tree (where the app limits are stored), you need to put this in your .adef:
Then, when you start your transaction, specify “system:” at the start of the config tree path that you pass into le_cfg_CreateReadTxn().
le_cfg_IteratorRef_t iteratorRef = le_cfg_CreateReadTxn("system:/apps/hello2/cpuShare");
BUT, you shouldn’t give your sandboxed app write permission for the system tree. In fact, you should try to avoid giving your sandboxed app any access to the system tree at all. I understand in this case that you can’t get that cpuShare setting from anywhere else, so you don’t have much choice here, if you need access to that data, but I assume this is just for fun, because I can’t imagine why your app would really need to know this. Try to practice the “principle of least privilege” whenever you can. If you do need access to something like this, you can create a simple app that has access to the privileged data in the “system” tree and provides a simple IPC API (e.g., a simple GetCpuShare() function) that provides only the minimum data needed by another app running inside a separate sandbox. This makes it much harder for a hacker who compromises a more complex app (because complex apps have more bugs and are therefore easier to compromise) to gain access to the privileges granted to the smaller, simpler app.