On Sun, Apr 12, 2009 at 09:08:25PM +0530, Ritesh Raj Sarraf wrote: > Look at the "program.ERROR" part. That looks to be the error. And this is > immediately followed by the above exception. > I think this violation wasn't filtered properly or something weired happened > with the violation, that then further made the rest of the setroubleshoot > assumptions break. > But still, that shouldn't throw a KeyboardInterrupt.
Hi, A KeyboardInterrupt is just the Python way to report a signal (yes, this is particularly stupid), so this could be any signal (from SIGALARM to SIGINT ..). Maybe strace could help, or at least starting setroubleshoot manually in debug mode : # setroubleshoot -f --debug > > The logging to syslog is with setroubleshoot. Probably that should be the > starting poiint to see why and when setroubleshoot logs a "program.ERROR". > I think it might just be needing a check, that when a program.ERROR occurs, > it > should do something. > Need to check the sources... > > Hmm!! > I'm not sure. Probably, maybe, verify_avc() in src/avc_audit.py might have > some pointers. > Not sure what you mean .. There is one difference between Fedora and Debian on this part: Fedora has a specific policy for setroubleshoot while debian does not. This allows to avoid alerts generated by setroubleshoot itself by checking if the context of the alert is the same as setroubleshoot's current context. I had to bypass this check, until a specific policy is written (see debian/patches/10_remove_context_check.patch). I'm uploading the new version anyway, but I'm leaving this bug report open since it is not fully resolved imho. Regards, Pierre
signature.asc
Description: Digital signature
