On Sun, May 3, 2020 at 3:50 AM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Sat, 02 May 2020 23:55:02 -0400, Jeffrey Walton said:
I lost about four hours chasing inaccurate messages from Apache. It turns out SElinux was denying access, so the EPERM was not really accurate. But Apache saw EPERM or EACCESS and logged a message related to Posix permissions.
No, you had a permission problem. It isn't strictly confined to only Posix permissions. Note that if you use ACLs, you'll also get an EPERM if you don't have access.
As far as I know Posix does not authorize use of EPERM or EACCESS for SElinux. That is, SElinux should not be hijacking the error code.
And where exactly does Posix say that EPERM is *only* for permission issues with the user/group/world bits? (Hint: you can get EPERM for a program that creates a socket and then tries to bind to the broadcast address for the interface, or if iptables rejected the request).
The error codes Posix provides are in the context of of its permission framework.
I'm wondering why there is no error message for SElinux that would allow application to return a specific error when SElinux denies access to an object or operation.
And why would that be useful? What could a program do differently for a SELinux permission error than a Posix permission error?
I could get a useful error message and work on the problem, instead of wasting hours going down rabbit holes.
If the problem is that you don't know about the SELinux error messages, you should be learning about the auditd subsystem, setroubleshootd, sealert, and friends.
Why does SElinux not have its own error code?
Among other things, it means that programs potentially have to have special-casing in the error handlers, which are *already* code that doesn't get fully tested in most cases.
Why is that a bad thing? SElinux is an addon. I have no problem checking for seerrno or ESEPERM for its specific errors. Jeff