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

[Joshua Brindle <jbrindle@tresys.com>]

Stephen Smalley wrote:

>On Tue, 2005-09-13 at 23:33 -0400, Ivan Gyurdiev wrote:
>  
>
>>Yes, I agree here - the DEBUG system is really doing error handling...
>>it detects an error condition, and informs the caller of what went wrong 
>>at every level of
>>the function stack (at least that's how I use it in the user and port 
>>functions). It has no effect
>>if there is no error condition. Perhaps it's a misnomer.
>>    
>>
>
>To be precise, DEBUG() is providing supplemental information when an
>error occurs to help in debugging the underlying cause.  The error
>handling itself consists of just returning an error code up the call
>chain (although they aren't as informative as one might like).
>write_error() is likewise providing supplemental information when an
>error occurs, but is focused on just reporting informative error
>messages to the user rather than helping with debugging the underlying
>cause or the precise point of failure.
>
>  
>
Yes, and I think we all agree that we need better error reporting to the 
calling functions, we particularly need this in things like linking and 
expanding where alot of stuff happens deep in libsepol and there are 
many possible error, conditions, many of which the user needs to know 
about in order to fix the policy (dependancy problems, etc)

>write_error() is also limited to a single error message, whereas DEBUG()
>can emit any number of messages during a single operation.  This shows
>up particularly in the assertion checking code where we'd like (at least
>for checkpolicy) to report all assertion violations in one pass.
>Similarly, it would be nice if the hieararchy checking code could report
>all violations in one pass (and if it provided more detail about the
>actual cause of the violation).
>  
>

Fair enough, for things like assertion and hierarchy checking we can 
pass a function pointer in and use the same basic system without the 
global DEBUG function pointer and still get what we want there. If we 
tried to use DEBUG for error reporting (as I think Ivan is suggesting) 
the calling function wouldn't get an error code, and thus check it's own 
error state until the first call in the chain and could potentially lose 
information. Having the specific error from the lowest point of failure 
seems much more useful than getting a less and less specific error from 
each funtion while propagating error codes.

I know modifying every function in sepol to use a write_error like 
system is undesirable but libsemanage already has write_error used 
exclusively so going to DEBUG with it also seems undesirable. 
libsemanage already passes a handle which contains an error buffer which 
gives us thread safety and the ability to easily return errors in a way 
the client app can use them (semodule will probably just print them out, 
whereas the policy server will have to do more).

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