SElinux and its own error code?

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

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

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

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.

And then you have to add code for Smack permission problems, and for
AppArmor permission problems, and Yama permission problems...

Or you can just return -EPERM for all of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200503/24e8bf91/attachment.sig>