~alpine/devel

3 2

[alpine-devel] Firefox not starting for normal user after Xorg update

Paul Onyschuk <blink@bojary.koba.pl>
Details
Message ID
<20140719121811.b5989b5aa59ffcac0a40333b@bojary.koba.pl>
Sender timestamp
1405765091
DKIM signature
missing
Download raw message
Alpine Edge x86_64, after Xorg update launching Firefox by normal user
(in video group):

[   39.116209] firefox[1597]: segfault at 8 ip 00006ba1e25a296d sp
00007b56f8e9fdd0 error 4 in i915_dri.so[6ba1e2355000+65f000 ]

[   39.116239] grsec: Segmentation fault occurred at 0000000000000008
in /usr/lib/firefox-30.0/firefox[firefox:1597] uid/euid: 1000/1000
gid/egid:1000/1000, parent /usr/lib/firefox-30.0/firefox[firefox:1595]
uid/euid:1000/1000 gid/egid:1000/1000

[   39.116259] grsec: bruteforce prevention initiated for the next 30
minutes or until service restarted, stalling each fork 3 0 seconds.
Please investigate the crash report for /usr/lib/firefox-30.0/firefox
[firefox:1597] uid/euid:1000/1000 gid/egid:10 00/1000,
parent /usr/lib/firefox-30.0/firefox[firefox:1595] uid/euid:1000/1000
gid/egid:1000/1000

[   39.116281] grsec: denied resource overstep by requesting 4096 for
RLIMIT_CORE against limit 0 for /usr/lib/firefox-30.0/fi refox
[firefox:1597] uid/euid:1000/1000 gid/egid:1000/1000,
parent /usr/lib/firefox-30.0/firefox[firefox:1595] uid/euid:1000/10 00
gid/egid:1000/1000

On the other hand with elevated privileges e.g. by "sudo firefox" it
starts just fine.  Did Xorg update introduce some change, when it comes
to permissions - requirement for different group?

-- 
Paul Onyschuk


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Paul Onyschuk <blink@bojary.koba.pl>
Details
Message ID
<20140719140541.dfcee7a97457e56d133c91bc@bojary.koba.pl>
In-Reply-To
<20140719143135.53ab1d17@vostro> (view parent)
Sender timestamp
1405771541
DKIM signature
missing
Download raw message
On Sat, 19 Jul 2014 14:31:35 +0300
Timo Teras wrote:

> I bumped into this exact same issue just yesterday. It seems to be
> grsec preventing access to /sys (by modifying the default
> permissions). And apparently the new i915 module wants to open stuff
> there. Not sure if we should patch grsec, the driver, or somehow
> adjust the /sys permissions. Should probably ask from grsec people
> what to do.

Looking at source code of xf86-video-intel [1] functions accessing
sysfs are guarded by #ifdef __linux__ in intel_device.c (for other
system lacking sysfs e.g. *BSD).  Otherwise this happens:

#else
static int __intel_open_device__pci(const struct pci_device *pci)
{ return -1; }
#endif

And it falls back to legacy method:

fd = __intel_open_device__pci(pci);
if (fd == -1)
	fd = __intel_open_device__legacy(pci);

Dirty workaround for time being could be just changing "#ifdef
__linux__" to "#if 0" in intel_device.c (or I'm missing something?),
before clearing this out with grsec people.


[1]
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_device.c

-- 
Paul Onyschuk


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20140719143135.53ab1d17@vostro>
In-Reply-To
<20140719121811.b5989b5aa59ffcac0a40333b@bojary.koba.pl> (view parent)
Sender timestamp
1405769495
DKIM signature
missing
Download raw message
Hi,

On Sat, 19 Jul 2014 12:18:11 +0200
Paul Onyschuk <blink@bojary.koba.pl> wrote:

> Alpine Edge x86_64, after Xorg update launching Firefox by normal user
> (in video group):
> 
> [   39.116209] firefox[1597]: segfault at 8 ip 00006ba1e25a296d sp
> 00007b56f8e9fdd0 error 4 in i915_dri.so[6ba1e2355000+65f000 ]
> 
> On the other hand with elevated privileges e.g. by "sudo firefox" it
> starts just fine.  Did Xorg update introduce some change, when it
> comes to permissions - requirement for different group?

I bumped into this exact same issue just yesterday. It seems to be
grsec preventing access to /sys (by modifying the default permissions).
And apparently the new i915 module wants to open stuff there. Not sure
if we should patch grsec, the driver, or somehow adjust the /sys
permissions. Should probably ask from grsec people what to do.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20140719153804.0fea8fde@vostro>
In-Reply-To
<20140719140541.dfcee7a97457e56d133c91bc@bojary.koba.pl> (view parent)
Sender timestamp
1405773484
DKIM signature
missing
Download raw message
On Sat, 19 Jul 2014 14:05:41 +0200
Paul Onyschuk <blink@bojary.koba.pl> wrote:

> On Sat, 19 Jul 2014 14:31:35 +0300
> Timo Teras wrote:
> 
> > I bumped into this exact same issue just yesterday. It seems to be
> > grsec preventing access to /sys (by modifying the default
> > permissions). And apparently the new i915 module wants to open stuff
> > there. Not sure if we should patch grsec, the driver, or somehow
> > adjust the /sys permissions. Should probably ask from grsec people
> > what to do.
> 
> Looking at source code of xf86-video-intel [1] functions accessing
> sysfs are guarded by #ifdef __linux__ in intel_device.c (for other
> system lacking sysfs e.g. *BSD).  Otherwise this happens:

I think that code runs only in X server? The code running as library is
likely part of Mesa, which likely calls libudev. Though, I did not
bother to check which is the exact place for doing the /sys stuff.

I just posted the strace. See:
https://forums.grsecurity.net/viewtopic.php?f=3&t=4012

And yes, the problem seems to affect GL enabled X-stuff, e.g. same
issue happens video players (vlc, mpv) but only when they are using gl
output module.

/Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)