From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: noloader@gmail.com
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: SElinux and its own error code?
Date: Sun, 03 May 2020 03:50:42 -0400 [thread overview]
Message-ID: <167275.1588492242@turing-police> (raw)
In-Reply-To: <CAH8yC8kjRr29R8=zeUuyE5NKVDMZsdHMh+Z9a9mgP51VWYu-jQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1747 bytes --]
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.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2020-05-03 7:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 3:55 SElinux and its own error code? Jeffrey Walton
2020-05-03 7:45 ` Greg KH
2020-05-03 7:50 ` Valdis Klētnieks [this message]
2020-05-03 7:59 ` Jeffrey Walton
2020-05-03 9:18 ` Greg KH
2020-05-03 16:02 ` Bernd Petrovitsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=167275.1588492242@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=kernelnewbies@kernelnewbies.org \
--cc=noloader@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.