Re: Friendlier EPERM - Request for input

["Dr. David Alan Gilbert" <dave at treblig dot org>]

* Eric Paris (eparis@redhat.com) 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"?

It's not just file access that's the problem (although with all the security
layers it's probably one of the more complex ones).

I've wasted way too much time trying to figure out why mmap (for example)
has given me an EINVAL; there are just too many holes you can fall into.

I've wondered in the past about using more bits of errno; making the
standard syscalls mask those out (when -ve), and making a new syscall that
returns the whole lot; that probably doesn't provide you enough for file
stuff though (unless it provided an index into your buffer?).  So that
shouldn't break an existing libc, but a new one would have a chance
at a better errno.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/