| 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: <20130109205947.GE26036@sunsite.ms.mff.cuni.cz> Date: Wed, 9 Jan 2013 21:59:48 +0100 From: Jakub Jelinek <jakub@...hat.com> To: Casey Schaufler <casey@...aufler-ca.com> Cc: Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org, libc-alpha@...rceware.org, dwalsh@...hat.com, dmalcolm@...hat.com, sds@...ho.nsa.gov, segoon@...nwall.com, linux-security-module@...r.kernel.org Subject: Re: Friendlier EPERM - Request for input On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote: > I'm suggesting that the string returned by get_extended_error_info() > ought to be the audit record the system call would generate, regardless > of whether the audit system would emit it or not. What system call would that info be for and would it be reset on next syscall that succeeded, or also failed? The thing is, various functions e.g. perform some syscall, save errno, do some other syscall, and if they decide that the first syscall should be what determines the whole function's errno, just restore errno from the saved value and return. Similarly, various functions just set errno upon detecting some error condition in userspace. There is no 1:1 mapping between many libc library calls and syscalls. So, when would it be safe to call this new get_extended_error_info function and how to determine to which syscall it was relevant? Jakub -- 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