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

From: Paul Onyschuk <[email-masked]>
Date: Sat, 19 Jul 2014 12:18:11 +0200

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:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Sat, 19 Jul 2014 14:31:35 +0300

Hi,

On Sat, 19 Jul 2014 12:18:11 +0200
Paul Onyschuk <[email-masked]> wrote:

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

---

---

From: Paul Onyschuk <[email-masked]>
Date: Sat, 19 Jul 2014 14:05:41 +0200

On Sat, 19 Jul 2014 14:31:35 +0300
Timo Teras wrote:

> 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

---

---

From: Timo Teras <[email-masked]>
Date: Sat, 19 Jul 2014 15:38:04 +0300

On Sat, 19 Jul 2014 14:05:41 +0200

> 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

---