question on persistent security context storage

[Andy Warner]

Hello,

I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) 
that is characterized by:

1. The need to store a security context (in some recoverable form) in 
our persistent database (storage size of the context is an important factor)
2. The need to frequently perform a high number of security access 
checks in a performance sensitive way

My question relates to the first characteristic from above. I am having 
trouble deciding on the best way to store the security context in the 
database. From my research I  see (I think!) three different 
representations for a security context: 1) string; 2) raw; 3) SID. 

The string representation, generally, seems clear as this is what is 
shown in all documentation as the context representation that exists in 
user space. My only question regarding the string representation is: is 
there is any hard limit to the length of the security context string? Do 
I need to allow for no theoretical size limit on a context string if I 
choose to store it?

I am inferring the the raw representation exists from seeing *_raw 
functions (e.g., security_compute_create_raw) referenced in selinux 
header files. Other than seeing these functions declared I am having 
trouble finding out much about a raw representation. Is there any 
advantage to storing/manipulating a context in its raw representation? 
That is, are they more suited for a fast security access check, are they 
smaller in size, or do they have a fixed or maximum length?

The SID I have also seen mentioned in various documentations but can 
determine little about them. My guess is that they are an integer value 
that is used for fast internal access, particularly for the AVC. Are 
SIDs indeed integer values? Are they persistent or are they meaningful 
only for a particular OS session?

I have also considered maintaining my own internal, persistent mapping 
between string based contexts and an integer representation, the mapping 
being stored/indexed inside the DBMS. This gives me a small storage 
overhead with a fixed size.

Any answers, pointers to documentation, or other help would be greatly 
appreciated!

Andy Warner