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