[ libsepol 6/6] Summary

[ libsepol 6/6] Summary

[Ivan Gyurdiev]

There is no 6/6.. i started counting at 0.
Just wanted to mention some things:

- Note that no new functions are exposed
via the shared interface, following the plan
to make this library static.

- Hopefully internal data structures can
eventually be removed from headers, and
we can rely on external data structures.

- If you have complaints about the API,
please let me know, and I'll fix it - I
received no comments on my users patch
when I posted it last time, so I followed
the same approach.

- Checkpolicy code should be routed to those new
functions, and so should libsemanage.

- I haven't put in a scope check (is_id_in_scope),
which checkpolicy currently does -
I didn't understand quite how that works. 
If it is necessary, please let me know.

- manpages still need to be written


--
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: [ libsepol 6/6] Summary

[Joshua Brindle]

Ivan Gyurdiev wrote:

>There is no 6/6.. i started counting at 0.
>Just wanted to mention some things:
>  
>
meh.

>- Note that no new functions are exposed
>via the shared interface, following the plan
>to make this library static.
>
>- Hopefully internal data structures can
>eventually be removed from headers, and
>we can rely on external data structures.
>
>  
>
probably not, there isn't really a need to add a layer of abstraction 
between checkpolicy and libsepol as checkpolicy is very tied to the 
policydb structure.

>- If you have complaints about the API,
>please let me know, and I'll fix it - I
>received no comments on my users patch
>when I posted it last time, so I followed
>the same approach.
>
>- Checkpolicy code should be routed to those new
>functions, and so should libsemanage.
>
>- I haven't put in a scope check (is_id_in_scope),
>which checkpolicy currently does -
>I didn't understand quite how that works. 
>If it is necessary, please let me know.
>
>  
>
Depends on what you are doing. The scope checks to see if symbols being 
refered to are in scope. In the module language there is an optional 
command that has a scope different from the global (symbols required for 
the optional to be activated are added to the active scope).

For purely monolithic policies it won't have an effect but with modules 
it must be done to ensure internal consistency in the policy.

>- manpages still need to be written
>  
>
don't you mean info pages ;)



--
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: [ libsepol 6/6] Summary

[Ivan Gyurdiev]

> Depends on what you are doing. The scope checks to see if symbols being 
> refered to are in scope. In the module language there is an optional 
> command that has a scope different from the global (symbols required for 
> the optional to be activated are added to the active scope).
> 
> For purely monolithic policies it won't have an effect but with modules 
> it must be done to ensure internal consistency in the policy.

I am checking if a context is valid. I don't have the slightest idea
where the context came from - whether it's from a module language,
or policy language, or any kind of language at all, as opposed
to some database. 

>From what you're saying, it sounds like this scope stuff would only go
into checkpolicy & co, not in any of the libsepol code.


--
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: [ libsepol 6/6] Summary

[Joshua Brindle]

Ivan Gyurdiev wrote:

>>Depends on what you are doing. The scope checks to see if symbols being 
>>refered to are in scope. In the module language there is an optional 
>>command that has a scope different from the global (symbols required for 
>>the optional to be activated are added to the active scope).
>>
>>For purely monolithic policies it won't have an effect but with modules 
>>it must be done to ensure internal consistency in the policy.
>>    
>>
>
>I am checking if a context is valid. I don't have the slightest idea
>where the context came from - whether it's from a module language,
>or policy language, or any kind of language at all, as opposed
>to some database. 
>
>  
>
right, but the policydb format can include scoping information so 
therefore you should check it, but only if it's a non-expanded policy.

>>From what you're saying, it sounds like this scope stuff would only go
>into checkpolicy & co, not in any of the libsepol code.
>  
>
No, the scope is preserved in the module format so anything that works 
with modules will need to handle it. I'll have to think about the best 
place to add users into the policy, post-link or post-expand and that 
will really determine whether you need to worry about this.

--
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: [ libsepol 6/6] Summary

[John D. Ramsdell]

Joshua Brindle <jbrindle@tresys.com> writes:

> >- Hopefully internal data structures can
> >eventually be removed from headers, and
> >we can rely on external data structures.
> >
> >
> probably not, there isn't really a need to add a layer of abstraction
> between checkpolicy and libsepol as checkpolicy is very tied to the
> policydb structure.

Slat is tied to it too.  As with checkpolicy, it uses the static
version of the library, and follows lots of pointers.

John

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