Re: [ SEPOL/SEMANAGE ] Boolean record

[Ivan Gyurdiev <ivg2@cornell.edu>]

>I agree that the duplication is strange, but I think that we should move all
>of these into libsemanage - I'm looking through them now and I don't see
>much reason for them to be in libsepol. This will only manage the files that
>store the users, right? Is the only goal a shared parser for the files? Same
>thing for ports.
>  
>
No - the semanage functionality is to extract data from a backend or 
write data to a backend, and to relay the corresponding objects to sepol 
to load (loading it itself breaks the encapsulation that I've been 
trying to create for sepol). The sepol functionality will be to actually 
load the data. Currently we're discussing the same data, hence the 
shared data structures, without modification. However, I'm not sure 
whether this will stay like that in the future - maybe we'll decide to 
store extra data in semanage that doesn't get passed down to the sepol 
layer. That's why I'm hesitant to use sepol data structures in semanage 
function headers.

>The inlined functions definitely don't make sense - the goals as I see them
>are:
>
>1) API/ABI stability
>2) The ability to move between straight modules and the policy server.
>
>The inlined functions don't meet this goal and moving things to libsepol
>will make 2 impossible.
>  
>
Can you clarify that point - I'm not sure I understand the problem. 
Perhaps it's an issue with inlined
functions that I'm not understanding - they're currently inlined for 
speed only, and that can easily be changed.
The point is to share the data structures with sepol, so the code 
doesn't have to be written twice.

--
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.