lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20130112202747.GA13942@gallifrey> Date: Sat, 12 Jan 2013 20:27:47 +0000 From: "Dr. David Alan Gilbert" <dave@...blig.org> To: Eric Paris <eparis@...hat.com> Cc: linux-kernel@...r.kernel.org, libc-alpha@...rceware.org, dwalsh@...hat.com, dmalcolm@...hat.com Subject: Re: Friendlier EPERM - Request for input * Eric Paris (eparis@...hat.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 |_______/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists