Security policy against two secure IDs?

[mrtj]

Hi,

I would like to define a P/S property that can be accessed from exactly 2 processes. As far as I understand when defining a P/S flag one has to use the _LIT_SECURITY_POLICY macros in order to restrict the access to that property. I found the _LIT_SECURITY_POLICY_S0 macro that restricts accessing only for 1 process, but is it possible somehow to allow the access for exactly two processes (and no other)? Can you OR these macros or something similar? _LIT_SECURITY_POLICY_S1..3 adds only capability restrictions.
By the way it is funny but if you use _LIT_SECURITY_POLICY_S0 with a secure id other than the defining process, even the defining process can not access the flag!

Thank you,
J.

[wizard_hu_]

Does not the support for separate read and write policies fulfil your needs?
What is the use case?

[mrtj]

I am currently implementing a watchdog process that would start a GUI application at boot time and later if the application exits it restarts it. But Symbian requires that the autostart should be able to be disabled by the user. This can be set of course only from the UI, but the watchdog has to read it before starting the GUI.
The most natural way would be to use Central Repository but earthborn 3rd party developers may not define new cenrep settings without paying a nice sum to our favorites.
So I came to the solution to define a P/S flag in the watchdog process that can be read and written from the GUI. The watchdog also observes the change of the flag and writes it to a file in its private folder in order to add persistence to the setting and publish it at boot time with the last saved value. This is the reason why both process have to read and write the same flag, but for security reasons I would like to prohibit all other processes to access this setting.

[ltomuta]

The client can call the launcher process with a certain command line parameter.

Or if the PS key is used, wizard_hu_ is right, if only the client can write the key and only the launcher can read then the problem is solved.

[Paul.Todd]

But Symbian requires that the autostart should be able to be disabled by the user

You could apply for a waiver, however it is more likely you would be told to fix the problems in the GUI code as that is the real problem here.

You could of course make the UI start and this could start the watchdog which would solve the problems and as Lucian said, you can pass command line parameters.

There are compatible examples on the wiki showing how to do the startup correctly in an application

[mrtj]

Hi, thank you for the replies. The point is that I would not like to start the GUI at each boot time only just to realize that I have to shut it down immediately (if the autostart setting is switched off). I was thinking it is better to start only a small exe, the watchdog, and it could decide itself whether to start the GUI or not.
On the other hand to do so the watchdog should know about the setting before starting the GUI thus the setting has to be stored in its domain (private dir for example). This means that the watchdog has also to write it when it is updated (reasons for reading/writing in the watchdog). The GUI essentially has only to write (when the user changes the setting), but it will be very user friendly if the GUI could also present the current value of the flag for the user thus he doesn't have to be "blind" when updating it. These are my reasons for reading/writing by the GUI.
I saw autostart examples and read this article at FN knowledge base http://wiki.forum.nokia.com/index.ph...oot_dynamic%3F. In the 1) proposal it talks about an ini file but keeps silence humbly about where one should place that ini. Basically have no problem autostarting at boot time or starting an exe and passing some command line parameters but I really do not know how this (command line) could help me.

[wizard_hu_]

Two comments:
- remember that P&S properties do not survive a reboot, so you can not use them for controlling startup-behavior (that is the Central Repository what you probably mean)
- since this kind of information is not that confidential, you may simply create it readable by everyone, but writable by your setter application only

[ltomuta]

An *.ini in a public location can solve the problem. If you have security concerns then make the launcher store its setting in the private folder.

a)
User changes the setting: autostart:on -> autostart:off

client calls launcher with "-a Off"

launcher starts, saves the new setting in private folder, exits

Identical scenario for switching the setting on

b)
Client and launcher communicate trough PS key. Launcher is always running and listening to key change events but can only read the value. Client may only write the value when needed so that the launcher reads and stores the new value.

[wizard_hu_]

My vote is for "b)" :-)

[ltomuta]

b) implies the launcher becoming a watcher, one more useless process lurking in the background, waiting for a setting change that will hardly ever happen

One might mix a) and b) so that the launcher is started by the client, reads the PS key and then exits but I wonder if there's anything to gain.

[mrtj]

At last I managed to explain my problem so that at least somebody partially understands it

Wizard 1) exactly that's why I need to store its value in an (ini) file at the watchdog side
Wizard 2) and ltomuta b) if only the GUI can write the P/S key then how can the watchdog publish its stored value that the GUI could present to the user?

I'll try to present the scenario step by step.

1) OS starts the watchdog.
The watchdog:
2) reads the value of the setting from the ini file
3) defines a P/S flag
4) sets the P/S flag to the value read from the file
5) subscribes to receive notifications on the change of the flag
6) starts the GUI if the setting is "On" (if it is "Off" it simply exits)
7) keeps running (in fact it Logons to the GUI process and restarts it if it exits but this is not relevant)

8) The user opens the settings page in the GUI
9) The GUI reads the value of the P/S flag and present to the user
10) The user changes the setting value
11) The GUI sets the P/S flag with the new value
12) The watchdog receives notification about the change
13) It reads the new value and updates the ini file

I hope I could clarify why in this scenario both GUI and watchdog have to read and write the flag. If I would like to keep at least the writing protected - thus not allowing everybody to do it - how could I solve this restriction?

[ltomuta]

The client owns the data and has its own settings stored in its own private folder. Client's setting overrides launcher's setting.

The client does not necessarily require any feedback from the watcher but for a) the return code can be used and for b) a second key with revers access rights can be used.

[ltomuta]

For more advanced use cases nothing stops you from implementing your own "CenRep" server and allow as many clients store as many settings under his private storage. For an Autostart On/Off that is however too much to ask.

[mrtj]

Thank you guys, I think my preferred solution will be a pair of P/S keys as ltomuta wrote, one for launcher -> client communication the other for client -> launcher direction. I simple did not think about this rather simple solution (if one may use the word "simple" at all in this scenario ) By the way this is an answer also for the original question. To make a setting shared exactly between two processes in a way that both can read/write it but no one else, you should use two P/S flag for both directions of communication and "cross-restrict" the access to the flags. However it needs some additional coding to keep the two flags synchronized.