linux-kernel - Re: Friendlier EPERM

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1357765795.1342.21.camel@localhost>
Date:	Wed, 09 Jan 2013 16:09:55 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Jakub Jelinek <jakub@...hat.com>
Cc:	Casey Schaufler <casey@...aufler-ca.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, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
> 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?

I was thinking of it to be the last kernel error.  So if the first and
that second operation caused the kernel to want to make available
extended errno information you would end up with the second.  I see this
is an informative piece of information, not normative.  Not a
replacement for errno.  I'm hoping for a best effort way to provide
extended errno information.

It would be really neat for libc to have a way to save and restore the
extended errno information, maybe even supply its own if it made the
choice in userspace, but that sounds really hard for the first pass.

I mean it would be great if we could rewrite every system call with a
cookie so userspace could reliably match things back up, but I just
don't see that as practical.  Instead we do the best we can and help
admins and developers most of the time, instead of none of the time.

-Eric

--
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/