Re: Friendlier EPERM - Request for input

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Jan 09, 2013 at 11:04:23AM -0500, Eric Paris wrote:
> Getting an EPERM/EACCES in userspace really kinda blows.  As a user you
> don't have any idea why you got it.  It could be SELinux, it could be
> rwx bits on the file, it could be a missing capability, it could be an
> ACL, it could be who knows what.  We'd like to start figuring out the
> who knows what and hopefully find a way to expose that to userspace.  My
> initial thought is a small buffer in the task struct in which the kernel
> can dump some data when it is going to send back an EPERM.  I was
> thinking of exposing that data via a /proc/self/task/[tid]/file which
> userspace could poll after an EPERM.  The hope would be to all userspace
> a better understanding of why it failed.  Wouldn't it be nice if instead
> of httpd log just saying 'permission denied' it would be able to say
> 'permision denied because the file was 640"?

For httpd, it would be nicer if the message is "not found" or similar
(i.e. printing the same error message for all conditions). Leaking
information to the public web about your web server misconfiguration
is a recipe for security disasters.

> I was thinking this buffer would look something like (very pseudo codie)
> 
> struct friendly_response {
>         enum { NONE, CAPABILITIES, SELINUX, FILE_PERMS } type;
> [...]

I think a binary structure is a very bad design. I also think
enlarging the task structure, especially with stuff that's useless to
most people and most applications, is a bad idea. And of course
there's the issue somebody else already mentioned with signal handlers
possibly clobbering the state and not being able to restore it
(if for no other reason, because they don't even know it exists).

What about just having a single syscall, comparable to access(), for
requesting the reason a particular attempt at access is not possible?
It would not be atomic (i.e. when the filesystem is changing, the
result might fail to match the reason an earlier access attempt
failed), but it would be a lot cleaner than carrying around state you
probably don't even need and making error status more stateful.

Anyway, I think this is more of a discussion for LKML than glibc.

Rich