Re: [ SEPOL ] Move more things to newer debug system

[Ivan Gyurdiev <ivg2@cornell.edu>]

>>Yes, I wouldn't expect the callback to have the logic to do that - 
>>that's just a question of policy on how you use the debug system in your 
>>code, and at which point you issue error messages.
>>    
>>
>
>Yes, but if the messages are generated in such a form that you need them
>all (or at least pieces of several of them) to make sense of the overall
>error, then it becomes difficult to implement a sensible callback that
>does anything other than output/log/buffer them all (optionally without
>the function information).  They can certainly differentiate between
>LOG_INFO, LOG_DEBUG, and LOG_ERR, but I think all current DEBUG calls
>would be LOG_ERR.
>  
>
Well, perhaps I should make an effort to generate errors in a different 
pattern, so the end result is more user friendly (possibly pass down 
more information to the leaf, so it can generate a single error report). 
In any case, I am concerned about semanage code here, specifically, 
semanage code that hasn't been merged yet that uses polymorphism. I'm 
not sure how much of a problem the current sepol code is...

>>Which part, specifically, seems like overkill?
>>    
>>
>
>If the policy management daemon was going to just discard all messages
>except for the leaf node error handling ones, then add ng a state object
>to the interfaces and pushing it down to all DEBUG calls seemed
>pointless; the result would never be used for most of them.  OTOH, you
>would still need the state object for all interfaces used by the policy
>management daemon, and you would need to push it down to all leaf node
>error handlers (whether they would call DEBUG or a separate write_error
>interface), so I suppose it might not make a large difference.
>  
>
Yes, you would still need the state object at the leaf node. 
Alternatively you could make use of more informative error codes in the 
leaf node, and print errors higher up. You need the state object at the 
point where the error is printed.

I think if we should wrap policydb into this so-called "state object" 
for the added benefit of eliminating the global policydb.

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