Re: Iptables discussion

[Joshua Brindle <jbrindle@tresys.com>]

<snip>

>Speaking of which... I'm duplicating your sepol_*_t records
>almost one-to-one in the libsepol api. I don't see a way around 
>that, however, because they are located in libsemanage.
>
>  
>
Why do you need them in libsepol? You don't need or want opaque types in 
libsepol, libsepol is a direct representation of the policy data 
structures. All the abstracted structures go in libsemanage.

<snip>

>It does matter, because I can write patches against it, and not write
>semod_ everywhere that I need to fix later.
>
>  
>
We aren't writing patches right now, we are trying to design a library. 
I'm really asking for your help to flesh out what is required for this 
API to work so that we can actually implement it.

>> Probably the best thing would be to write your user and port 
>>management stuff against the new API and see if it actually works.
>>    
>>
>
>I can't see if actually works, because there is no library to test it
>with. It used to work when it was in libselinux... I'm sure I'll have
>to change it a bit to fit with your structure names, and your apis,
>and your transaction processing.
>
>  
>
I mean that it works conceptually, ie: the API provides everything you 
need. Compiling and testing is very irrelavent right now since we are 
trying to design a very abstract management API for SELinux, something 
that needs to be carefully designed.

>>semanage_user_change(semanage_handle_t *, semanage_user_t *userdata, 
>>char* key);
>>it would totally replace the datum, no unioning or anything like that
>>    
>>
>
>If you're assuming character key, please assume character key in
>the delete functions as well. I'm not against it, simply pointing out..
>
>  
>
or we make opaque types for all keys and all datums just incase we want 
a composite key later.

>The drawback to not providing any more specific change functions 
>to the caller, is that now you have to do a query and a change for
>everything, even if all you're doing is adding information, and not
>extracting any. That means two iterations in the flat file case...
>but for the sake of simplicity and cleanness of API, maybe I'll agree.
>
>However, not having a query function is just wrong, I disagree with
>that.
>  
>
We'll add them, they are just convenience functions that will be added 
as needed.


Please, please stop focusing on the implementation details and help with 
the API design, I really need to know if this is sufficient for you 
(sans the labeling stuff that we are still working out). This is going 
to be an API that is used by every single tool that manages policy and 
it needs to be well thought out and flexible.

Joshua

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