Central Repository & Vendor ID

Hi,

1. is it possible to define a security policy for a central repository file such that the system will check if the application which accesses the central repository file has a specific Vendor ID?
2. if not, is it possible to define a security policy for a central repository file with multiple SIDs such that the system will check if the application which accesses the central repository file is one of these specific SIDs?

What I need is that a group of co-operating applications need to be able to access my central repository file and other applications should not be able the access my central repository file.

BR,

Rene

Considering that the creation of a Central Repository itself is subject to a partnering agreement with Symbian the answer to both questions would be ... ask Symbian (or consult the documents received).

As far as I remember the policies can only be defined based on Secure ID, not Vendor ID. But if the documentation says otherwise trust the docs :)

Hi Rene,

Have a look at the "Central Repository How To" document (You might need to request this from Symbian as I am not 100% sure its in the BAK.

Section 3.3.4 covers how to restrict access to the repository.

I checked the documentation for the BAKs and in a lot of other places. They do not explicitly say protection using Vendor ID is not possible, but they also show no indication it is possible. Some small experiment did not result into a working solution using Vendor ID.

So I guess the answer is: no, protection can be not be done based on Vendor ID.

Basically so far I only discovered examples and documentation stating you can do protection based on a single SID.

Anyhow, thanks for the comments. BTW: You can create central repository files using public APIs with any S60 3rd SDK, so I do not think you need an additional agreement with Symbian for that.

In fact even the public SDK Help contains a summary, just search for something related, like [B]cap_rd[/B] or [B]sid_rd[/B], and select "Symbian OS Changes for Platform Security" if you have multiple hits:[QUOTE=SDK Help]Access policies:
...
are defined through security capabilities only (up to 7) or as a combination of SID and up to 3 capabilities.
...[/QUOTE]Indeed a bit strange decision, especially if it is compared to the C++ API level counterpart, TSecurityPolicy[QUOTE=SDK Help]This class can specify a security policy consisting of either:

A check for between 0 and 7 capabilities

A check for a given Secure ID along with 0-3 capabilities

A check for a given Vendor ID along with 0-3 capabilities[/QUOTE]It would not have hurt that much introducing "vid_rd/wr" policy for CenRep, but apparently that has not happened.

If you are really dedicated you can provide a single getter/setter server, obviously having a single SID (thus eligible for sid_wr policy), and in this case the server could do the VendorId checks.

Hi wizard_hu_,

thanks. Actually this was also our conclusion/escape - write a dedicated server which distributes the settings to the different co-operating applications/processes. I was hoping for a solution which costs a little less development time.

Actually quite strange, because it must have occurred to Symbian at the time they designed the central repository that a valid use case scenario would be a set of co-operating application which all need access to the same repository.

Shall I propose such an extension? I will need to propose it to Symbian, right?

BR,

Rene

[QUOTE=heuven;508946]
BTW: You can create central repository files using public APIs with any S60 3rd SDK, so I do not think you need an additional agreement with Symbian for that.[/QUOTE]

You can do many things using the public SDK and putting together some bits of info collected from the docs, SDK files and ... Symbian Signed certification criteria. Not all that you can figure out how to do is however also supported/public.

Some things to note:
- the Set methods in the Central Repository API are @publishedPartner
- the installation process requires the update of a Symbian SIS package which can only be done with Symbian's permission
- the lack of VID based policy is a good indication that the component is not yet mature which could be a decent excuse for it not being fully public.