[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTik8fv9SZ3_z0rVND_CrYBHmf67uvRQf2YanucjA@mail.gmail.com>
Date: Sun, 13 Feb 2011 09:15:46 +0100
From: Alex Riesen <raa.lkml@...il.com>
To: Dave Young <hidave.darkstar@...il.com>
Cc: linux-kernel@...r.kernel.org, David Airlie <airlied@...ux.ie>,
dri-devel@...ts.freedesktop.org, Chris Wright <chrisw@...s-sol.org>
Subject: Re: Regression - Xorg start failed
On Sun, Feb 13, 2011 at 07:22, Dave Young <hidave.darkstar@...il.com> wrote:
> Finally I bisected it, results:
> 47970b1b2aa64464bc0a9543e86361a622ae7c03 is first bad commit
> commit 47970b1b2aa64464bc0a9543e86361a622ae7c03
> Author: Chris Wright <chrisw@...s-sol.org>
> Date: Thu Feb 10 15:58:56 2011 -0800
>
> pci: use security_capable() when checking capablities during config space read
>
> Eric Paris noted that commit de139a3 ("pci: check caps from sysfs file
> open to read device dependent config space") caused the capability check
> to bypass security modules and potentially auditing. Rectify this by
> calling security_capable() when checking the open file's capabilities
> for config space reads.
>
> Reported-by: Eric Paris <eparis@...hat.com>
> Signed-off-by: Chris Wright <chrisw@...s-sol.org>
> Signed-off-by: James Morris <jmorris@...ei.org>
>
Actually, even reading the PCI capabilities fails with lspci
reporting "Capabilities: <access denied>" if run as root.
"libpciaccess" should have handled this situation, but still
it looks like a regression and it breaks existing systems.
--
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