Re: [PATCH 1/2] integrity: Add errno field in audit message

On 6/16/20 8:29 AM, Steve Grubb wrote: >>>>> The idea is a good idea, but you're assuming that "result" is always >>>>> errno. That was probably true originally, but isn't now. For >>>>> example, ima_appraise_measurement() calls xattr_verify(), which >>>>> compares the security.ima hash with the calculated file hash. On >>>>> failure, it returns the result of memcmp(). Each and every code path >>>>> will need to be checked. >>>> >>>> Good catch Mimi. >>>> >>>> Instead of "errno" should we just use "result" and log the value given >>>> in the result parameter? >>> >>> That would likely collide with another field of the same name which is >>> the >>> operation's results. If it really is errno, the name is fine. It's >>> generic >>> enough that it can be reused on other events if that mattered. >> >> Steve, what is the historical reason why we have both "res" and >> "result" for indicating a boolean success/fail? I'm just curious how >> we ended up this way, and who may still be using "result". > > I think its pam and some other user space things did this. But because of > mixed machines in datacenters supporting multiple versions of OS, we have > to leave result alone. It has to be 0,1 or success/fail. We cannot use > it for errno. As Mimi had pointed out, since the value passed in result parameter is not always an error code, "errno" is not an appropriate name. Can we add a new field, say, "op_result" to report the result of the specified operation?