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?
thanks,
-lakshmi
