Record keys

Record keys

[Ivan Gyurdiev]

(resent with correct list address this time)
> Please help me decide what to do with the record key for the record 
> structures which I've added into libsepol and libsemanage. Stephen has 
> now exported those functions into the shared library, so after an 
> official release, it would be good not to be changing those APIs.
>
> The job of the key is to identify a record uniquely among a collection 
> of the same record type.
> They do this by the record.compare(key) function. Currently the key is 
> required to be a subset of the record fields (so it has to be 
> contained within the record...does that make it useless? could this 
> change in the future, and how?)
>
> ================
> I added the key structure, because it just seemed wrong to pass an 
> "incomplete" record structure containing just the key fields 
> into..say...a query() handler. Note that the key constructor forces 
> the caller to specify all the fields (since this is a key, all fields 
> are required), while splitting this up into set calls to a record 
> structure could result in invalid keys.
>
> Currently keys are contained _within_ the record - they're a subset of 
> the record's fields. That's the primary reason why I ask whether keys 
> should be kept or not - a method called extract_key is supported....If 
> the key can be extracted from the record, you can use that on 
> modify(), and add() to pass a single argument (the record). That also 
> makes it easier for the caller (specify key fields in only one place, 
> instead of both in key and record). It's easy to just add the record, 
> but then the API just *looks* wrong..  also that prevents use of keys 
> that are not contained within the record in the future... but I'm not 
> clear as to whether this will ever change.
>
> If such "external" keys are to be used, then the extract_key method 
> can't be used (but there's nothing to require this method
> for each record - it's just expected internally to be implemented - 
> internals can easily change to fit what's required). Basically, I'm 
> trying to imagine a scenario where the key would not be contained 
> within the record, and what would be required to support that.
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Record keys

[Ivan Gyurdiev]

>
>> Please help me decide what to do with the record key for the record 
>> structures which I've added into libsepol and libsemanage. Stephen 
>> has now exported those functions into the shared library, so after an 
>> official release, it would be good not to be changing those APIs.
Joshua? No comments?
(see original message for details)

If nobody suggests anything, I am likely to leave the key in, and add a 
key_unpack function, and pass the key down to the sepol level....


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Record keys

[Joshua Brindle]

Ivan Gyurdiev wrote:
> (resent with correct list address this time)
> 
>> Please help me decide what to do with the record key for the record 
>> structures which I've added into libsepol and libsemanage. Stephen has 
>> now exported those functions into the shared library, so after an 
>> official release, it would be good not to be changing those APIs.
>>
>> The job of the key is to identify a record uniquely among a collection 
>> of the same record type.
>> They do this by the record.compare(key) function. Currently the key is 
>> required to be a subset of the record fields (so it has to be 
>> contained within the record...does that make it useless? could this 
>> change in the future, and how?)
>>
>> ================
>> I added the key structure, because it just seemed wrong to pass an 
>> "incomplete" record structure containing just the key fields 
>> into..say...a query() handler. Note that the key constructor forces 
>> the caller to specify all the fields (since this is a key, all fields 
>> are required), while splitting this up into set calls to a record 
>> structure could result in invalid keys.
>>
>> Currently keys are contained _within_ the record - they're a subset of 
>> the record's fields. That's the primary reason why I ask whether keys 
>> should be kept or not - a method called extract_key is supported....If 
>> the key can be extracted from the record, you can use that on 
>> modify(), and add() to pass a single argument (the record). That also 
>> makes it easier for the caller (specify key fields in only one place, 
>> instead of both in key and record). It's easy to just add the record, 
>> but then the API just *looks* wrong..  also that prevents use of keys 
>> that are not contained within the record in the future... but I'm not 
>> clear as to whether this will ever change.
>>
>> If such "external" keys are to be used, then the extract_key method 
>> can't be used (but there's nothing to require this method
>> for each record - it's just expected internally to be implemented - 
>> internals can easily change to fit what's required). Basically, I'm 
>> trying to imagine a scenario where the key would not be contained 
>> within the record, and what would be required to support that.
>>
> 
I can't think of any time a key wouldn't be within the record. I don't 
know what the problem is though, the record will always be serialized 
some way into a flat text file so you have to key_extract either way, if 
you keep a key around you do it once on read, if you don't you do it 
anytime there is a query, set, etc, it seems better to do it once.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Record keys

[Ivan Gyurdiev]

> I can't think of any time a key wouldn't be within the record. I don't 
> know what the problem is though, the record will always be serialized 
> some way into a flat text file
You keep keep referring to the problem I'm trying to solve as 
parsing/writing a flat text file. Please realize that records are 
supposed to be backend-independent data structures. In particular, I 
currently use them for transfer with a flat file, or a policydb object. 
I am hoping you can use them over the wire for the policy server... 
so..no, the record will not always go in a text file.

I understand the serialization argument...
There's the same problem with policy - the key is a bunch of primitives 
that need to be assembled together (and disassembled).
> so you have to key_extract either way, if you keep a key around you do 
> it once on read, if you don't you do it anytime there is a query, set, 
> etc, it seems better to do it once.
Sepol doesn't have much use for the key structure - it's mostly to 
benefit semanage polymorphism. Sepol would just disassembles the key 
back into its components to do a query. I need to add a function to do 
that, since currently the key is opaque.

Also, if the key is separate from the record, the user can do something 
stupid, like add a record with a mismatch key.
=======

Anyway, there's no significant problem here - either way is fine. I'm 
just trying to finalize the API.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.