Bug 581256 - SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access on oom_adj.
Summary: SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access o...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:ef77ad3e65d...
: 585966 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-11 12:56 UTC by Pau Aliagas
Modified: 2010-10-14 06:33 UTC (History)
32 users (show)

Fixed In Version: selinux-policy-3.6.32-123.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-14 06:33:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Pau Aliagas 2010-04-11 12:56:59 UTC
Resum:

SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access on
oom_adj.

Descripció detallada:

[chrome-sandbox has a permissive type (chrome_sandbox_t). This access was not
denied.]

SELinux denied access requested by chrome-sandbox. It is not expected that this
access is required by chrome-sandbox and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Permet l'accés:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Informació addicional:

Context de la font            unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c
                              0.c1023
Context de l'objectiu         unconfined_u:unconfined_r:unconfined_execmem_t:s0-
                              s0:c0.c1023
Objectes objectius            oom_adj [ file ]
Font                          chrome-sandbox
Camí de la font              /opt/google/chrome/chrome-sandbox
Port                          <Desconegut>
Ordinador                     (removed)
Paquests RPM font             google-chrome-beta-5.0.342.9-43360
Paquets RPM destí            
RPM de política              selinux-policy-3.6.32-110.fc12
S'ha habilitat el Selinux     True
Tipus de la política         targeted
Mode forçat                  Enforcing
Nom del connector             catchall
Nom de la màquina            (removed)
Plataforma                    Linux (removed) 2.6.32.10-90.fc12.x86_64 #1 SMP
                              Tue Mar 23 09:47:08 UTC 2010 x86_64 x86_64
Contador d'alertes            1
Vist per primera vegada       dg 11 abr 2010 14:23:39 CEST
Vist per darrera vegada       dg 11 abr 2010 14:23:39 CEST
Identificador local           5a9c5d9f-c347-4b31-8742-d8469a543057
Número de línies            

Missatges d'auditoria sense p 

node=(removed) type=AVC msg=audit(1270988619.557:1565): avc:  denied  { write } for  pid=15967 comm="chrome-sandbox" name="oom_adj" dev=proc ino=4752545 scontext=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_execmem_t:s0-s0:c0.c1023 tclass=file

node=(removed) type=SYSCALL msg=audit(1270988619.557:1565): arch=c000003e syscall=2 success=yes exit=3 a0=7fff8c5dee70 a1=1 a2=6a64615f6d6f6f2f a3=7fff8c5deb60 items=0 ppid=8759 pid=15967 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="chrome-sandbox" exe="/opt/google/chrome/chrome-sandbox" subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  catchall,chrome-sandbox,chrome_sandbox_t,unconfined_execmem_t,file,write
audit2allow suggests:

#============= chrome_sandbox_t ==============
allow chrome_sandbox_t unconfined_execmem_t:file write;

Comment 1 Daniel Walsh 2010-04-12 17:56:09 UTC
Please report this as a bug to chrome.  This is a leaked file descriptor, and allowing it would allow chrome_sandbox to prevent itself from being oom killed.  

I will not fix this in SELinux in that I consider it a potential problem in Systems that do not use SELinux.

Google/Chrome developers should set the close on exec flag after opening this file.

fcntl(fd, F_SETFD, FD_CLOEXEC)

Comment 2 Maciej Żenczykowski 2010-04-17 03:40:55 UTC
Reported at http://code.google.com/p/chromium/issues/detail?id=41853

Comment 3 Adam Langley 2010-04-19 14:57:24 UTC
Not a file descriptor leak.

In this case we're running the chrome-sandbox binary to use its SUID capabilities in order to set the OOM value for the child process. (Yep, it's a bit nasty. No argument there. Open to suggestions.)

However, if you don't want to open up oom_score for this then I'm happy to submit a change which tries to stat '/selinux' and, if found, doesn't try to adjust the OOM score.



AGL

Comment 4 Maciej Żenczykowski 2010-04-19 17:56:49 UTC
It's not clear to me why you need suid priviledges for that...
I can certainly write a '1' to /proc/$$/oom_adj without becoming root, and I don't see any chrome processes not running as myself.

Furthermore, do these settings stick around across exec?  Wouldn't it be enough to set them before the exec?

Comment 5 Daniel Walsh 2010-04-20 13:21:48 UTC
Looks like you only need privs to lower the oom_adj value.

If you set it in an unpriv process to 2 you can not set it back to 1 or anything less.  (10 seconds worth of testing.)

Comment 6 Daniel Walsh 2010-04-26 15:28:42 UTC
*** Bug 585966 has been marked as a duplicate of this bug. ***

Comment 7 Adam Langley 2010-05-07 18:09:35 UTC
Sorry for letting this slip though the cracks for so long...

1) You can't change the oom_adj of a non-dumpable process (EPERM) unless you're root. Because of this, we can't set the oom_adj from the browser process.
2) We can't set the oom_adj before entering the sandbox because the zygote is in the sandbox and the zygote is as critical as the browser process. Its oom_adj value shouldn't be changed.
3) A non-dumpable process can't even change its own oom_adj because it's root owned 0644. The sandboxed processes don't even have /proc, but one could imagine passing in a descriptor from outside.

I've run out of tricks for this case so I'm just going to disable oom_adj in the SELinux case.

Comment 8 Tyler Starke 2010-05-07 18:16:53 UTC
(In reply to comment #7)
> Sorry for letting this slip though the cracks for so long...
> 
> 1) You can't change the oom_adj of a non-dumpable process (EPERM) unless you're
> root. Because of this, we can't set the oom_adj from the browser process.
> 2) We can't set the oom_adj before entering the sandbox because the zygote is
> in the sandbox and the zygote is as critical as the browser process. Its
> oom_adj value shouldn't be changed.
> 3) A non-dumpable process can't even change its own oom_adj because it's root
> owned 0644. The sandboxed processes don't even have /proc, but one could
> imagine passing in a descriptor from outside.
> 
> I've run out of tricks for this case so I'm just going to disable oom_adj in
> the SELinux case.    

If that is the case I would prefer Google fix their access violation instead of SELinux being careless about it.

Comment 9 Adam Langley 2010-05-07 18:24:34 UTC
(In reply to comment #8)
> If that is the case I would prefer Google fix their access violation instead of
> SELinux being careless about it.    

I think that's what I just said.

Comment 10 Adam Langley 2010-05-07 19:34:31 UTC
Hopefully fixed by http://src.chromium.org/viewvc/chrome?view=rev&revision=46724

I think this bug can be closed.

Comment 11 Daniel Walsh 2010-05-07 20:36:55 UTC
Well wait a second.  Is adjusting the oom_adj making the chrome sandbox more likely to be killed?  If so then I think I have got to figure a way to allow this.

If comment 5 is correct I can add a label to oom_adj and then allow the sandbox to write to it.

Comment 12 Adam Langley 2010-05-07 20:45:03 UTC
We are adjusting oom_adj to make the renderer processes more likely to be killed. These processes are children of the zygote (which is important, and not adjusted). Killing a renderer just "Sad tabs" all the pages for a given domain.

If you're willing to change the policy to allow this then that works too.

Comment 13 Daniel Walsh 2010-05-11 15:22:30 UTC
Steven or Eric,  Is there a way to add a label to 

/proc/*/oom_adj

Such that I can say chrome_sandbox_t can write to its parents oom_adj field?

Comment 14 Stephen Smalley 2010-05-12 13:59:00 UTC
Not presently, no.  All /proc/pid inodes are labeled with the label of the associated task (security_task_to_inode).  Changes to the kernel would be required to support finer-grained labeling within /proc/pid.  Other (not per-process) /proc nodes can be individually labeled already via genfscon.

FWIW, testing for presence of /selinux is not a strong indicator of SELinux as it may just be an empty mountpoint if the distro ships SELinux support at all but it is disabled by default or disabled by the user.  Better to check whether there is something mounted there, e.g.
- statfs("/selinux", &buf) == 0 && buf.f_type == SELINUX_MAGIC -or-
- access("/selinux/enforce", F_OK) == 0

Comment 15 Daniel Walsh 2010-05-12 14:50:50 UTC
I guess then the question is what is the risk of allowing the chrome-sandbox from writing to /proc/PPID/*

Comment 16 Tyler Starke 2010-05-12 15:05:09 UTC
(In reply to comment #15)
> I guess then the question is what is the risk of allowing the chrome-sandbox
> from writing to /proc/PPID/*    

If you do that I think I will uninstall it. Does Firefox have that ability?

Comment 17 Daniel Walsh 2010-05-12 15:19:58 UTC
Firefox does not sandbox its content processing, so for this process it is still more secure then firefox.

When using firefox, you run it in the users context by default.  Probably unconfined_t so if you had a bug that is triggered by content, it could take over firefox.

If you use chrome it runs in unconfined_t but its sandbox runs in chrome_sandbox_t.  What we are looking at is allowing chrome_sandbox_t the ability to write to files under /proc/PID/ of the chrome application.

Comment 18 Tyler Starke 2010-05-12 15:46:27 UTC
(In reply to comment #17)
> If you use chrome it runs in unconfined_t but its sandbox runs in
> chrome_sandbox_t.  What we are looking at is allowing chrome_sandbox_t the
> ability to write to files under /proc/PID/ of the chrome application.    

yeah .. I don't like that part. I don't like giving Google Chrome more access to my system than I have on a regular basis.

I think the real problem resides in the fact that Google Chrome is in itself an OS, a Linux based fork, and Google has not fully separated the OS aspect from it's "browser" so Chrome is attempting to act like it is at home and do what it would normally do.

If you allow Google's Chrome more access than I have .... I uninstall it.

Comment 19 Stephen Smalley 2010-05-12 15:59:56 UTC
(In reply to comment #15)
> I guess then the question is what is the risk of allowing the chrome-sandbox
> from writing to /proc/PPID/*    

I wouldn't recommend allowing it.

First, the granularity is all wrong - you just want to allow this particular instance of the sandbox to write to the oom_adj file of the parent.  But the SELinux denial is in terms of the security contexts only, and can't distinguish this instance of the sandbox from any other, nor the parent from anything else running in unconfined_execmem_t, nor oom_adj from any other file in /proc/pid.

Second, it sounds like the only reason it is being done this way in the first place is as a compromise to address limitations introduced by the earlier decision to make the process non-dumpable.  And that in turn was motivated by a desire to block ptrace among the renderers?  But if they were just run in different contexts (e.g. just randomly generate and use a category like sandbox or svirt does), ptrace could be blocked based on that without impairing dumpability.

Comment 20 Tyler Starke 2010-05-12 16:31:57 UTC
(In reply to comment #19)
> (In reply to comment #15)
> > I guess then the question is what is the risk of allowing the chrome-sandbox
> > from writing to /proc/PPID/*    
> 
> I wouldn't recommend allowing it.
> 
Hey thanks for listening. I am done newbing up your geek talk here. I just wanted to say one last thing. 

With what Daniel is saying, Chrome is trying to write to the proc/PID/, and with the errors I am getting from Google on my Fedora 11 32bit machine I would have to say that Google's subprocessing / forked processing of their tabs is something Google needs to look at. I've been getting a new error, only after I open a new tab.

I think Google is trying to run an OS / Browser that is a fork of Linux without giving it a proper VM to live in. So it tries to act like it's at home, but it's not, it is a guest.

I thank Stephen for not recommending the allowance and Daniel for putting up with my newbery. And with that I am back to reading emails.

Comment 21 Maciej Żenczykowski 2010-05-12 19:54:30 UTC
> yeah .. I don't like that part. I don't like giving Google Chrome more access
> to my system than I have on a regular basis.

But, you _do_ have that access on a regular basis (as does any non-specially restricted/sandboxed process).

> I think the real problem resides in the fact that Google Chrome is in itself
> an OS, a Linux based fork, and Google has not fully separated the OS aspect
> from it's "browser" so Chrome is attempting to act like it is at home and do
> what it would normally do.

Calling Chrome an 'OS' and a 'Linux fork' is wrong on so many levels... I'm not sure there's any way you can look at that statement to see it as 'correct' (unless you subscribe to the entire 'the web is the OS' way of thinking).

> With what Daniel is saying, Chrome is trying to write to the proc/PID/, and
> with the errors I am getting from Google on my Fedora 11 32bit machine I would
> have to say that Google's subprocessing / forked processing of their tabs is
> something Google needs to look at. I've been getting a new error, only after I
> open a new tab.

Sure, new tab -> new renderer -> new sandbox/process -> on startup needs to be adjusted so it preferentially dies on OOM [Out of Memory: ie. memory exhaustion].  That's actually pretty sane.  The fact that there doesn't seem to currently be a sane way to give Chrome the ability to do that is the problem.  Chrome's behaviour is correct and desirable.  What broke down is the granularity of the security model.

This can be fixed in many ways:
* easy way: widen the privileges of a slightly less granular ACL (ie. grant access to /proc/PID/*) [ie. what was suggested here]
* hard way: rework the security of /proc in kernel so you can grant access to single files within /proc/PID (ie. /proc/PID/oom_adj) as opposed to just /proc/PID/* (like can be done currently)  [this is an easy change, hard to get accepted upstream, and hard to get rolled out]
* hard way: rework the way Chrome does sandboxing to potentially work around this problem  [this is a very complex change, but easy to get rolled out]
* stupid way (currently implemented) on selinux don't touch oom_adj and thus have other processes (like the X server) die on OOM instead of tabs of a browser (which is likely the memory hog anyway) - this is definitely sub-optimal.

> I think Google is trying to run an OS / Browser that is a fork of Linux
> without giving it a proper VM to live in. So it tries to act like it's at
> home, but it's not, it is a guest.

It's the responsibility of the kernel (ie. Linux) to provide to userspace (ie. Chrome) sufficient hooks/calls/functionality/etc. to make it possible to create a good sandbox.  Linux is currently a little lacking in this department - it is kind-of-sort-of doable, but very hard, very fragile, and extremely complex.

Comment 22 Tyler Starke 2010-05-12 20:02:58 UTC
(In reply to comment #21)
I know I am a newb, but please don't call me wrong. You can't toss away Google's ad campaign. What else am I supposed to think?    

Google Chrome OS: http://www.youtube.com/watch?v=0QRO3gKj3qw

Comment 23 Tyler Starke 2010-05-12 20:11:31 UTC
(In reply to comment #21)
> Calling Chrome an 'OS' and a 'Linux fork' is wrong on so many levels... I'm not
> sure there's any way you can look at that statement to see it as 'correct'
> (unless you subscribe to the entire 'the web is the OS' way of thinking).
  
Wait a minute! This is you? http://www.linkedin.com/in/maciejzenczykowski
And you have not subscribed to the 'statelessness' of Google Chrome OS? I quit! I am done with Google.

Comment 24 Daniel Walsh 2010-05-12 20:30:47 UTC
 Maciej,

Why cant the chrome-sandbox to set the oom_adj on itself, then have the tab process die when its chrome-sandbox gets killed?

Comment 25 Maciej Żenczykowski 2010-05-12 20:34:23 UTC
Okay I see what the problem is.  You are confusing "Chrome OS" with "Chrome".
I guess it is quite a confusing choice of names.

There is quite a significant difference between "Chrome" (the web browser) which is entirely a userspace application (and runs on Windows, Mac, various distributions of Linux, etc) and "Chrome OS" (which is a Linux based OS, which includes the 'Chrome' browser as a vital component - and this is where the 'Chrome OS' name comes from).

Now it is true, that from a user's perspective there may actually be little difference between 'Chrome' and 'Chrome OS', since the user visible UI [User Interface] of 'Chrome OS' is just (for the most part) the 'Chrome' browser.

However... from a technical standpoint the difference between 'Chrome' the browser and 'Chrome OS' the operating system is humongous.

This entire discussion/bug is about the Chrome browser and how it runs on Fedora Linux (which is the OS here).  It doesn't really relate in any particular way to "Chrome OS".

ie. think of it this way:
- "Chrome" the web browser is roughly a parallel to "Firefox" the web browser
- "Chrome OS" the operating system is basically a Linux distribution just like "Fedora" (or Ubuntu or Debian or any other Linux distro).

Fedora comes with Firefox by default (and you can install Chrome).

Chrome OS comes with Chrome by default (and you could install/hack Firefox onto it as well, although that's not really what it's meant for: it's supposed to be very light weight).

Comment 26 Adam Langley 2010-05-12 20:55:09 UTC
Dan: the SUID helper gets run and it sandboxes the Zygote process. The Zygote process (which is critical and shouldn't have its oom_adj changed) forks off the renderer processes. However, within the sandbox, /proc doesn't exist so we can't access it from there.

I'll make the change to reflect Stephen's suggestions for /selinux, otherwise I think this bug is taking more time than is warranted.

We have to start of 'real' SELinux support behind a #ifdef. If I get around to it, I'll do the trick of randomly selecting categories for each renderer.


Cheers

Comment 27 Maciej Żenczykowski 2010-05-12 20:56:06 UTC
Daniel,

I have no idea... I just happen to run Chrome (the browser) on my Fedora laptop and home desktop/media center.

I've never even looked at the browser source code (I'm just a very newb-ish kernel hacker...).

I remember there was some LWN article [ http://lwn.net/Articles/347547/ ] about Chrome sandboxing and something about using some secure computing (seccomp) aspect of the Linux kernel to lock down the rendering threads so that they have no syscall access besides read/write/sigreturn/exit.  I'm not sure if and how this fits into the picture here, but maybe the threads/processes in question have already been locked down so tight they can't do anything at that point???
[still not clear to be why they couldn't change oom_adj before they drop privs...]

[/opt/google/chrome]$ ls -alZ chrome chrome-sandbox 
-rwxr-xr-x. root root system_u:object_r:execmem_exec_t:s0 chrome
-rwsr-xr-x. root root system_u:object_r:chrome_sandbox_exec_t:s0 chrome-sandbox

Notice that chrome is 42MB while the setuid root chrome-sandbox is 14KB.

It's probably related to how (for memory savings) the zygote works.

Here's a guesstimate:  you launch the browser (chrome), the browser launches the zygote (chrome --type=zygote) which then forks of an instance of the renderer (chrome --type=renderer) or extension (chrome --type=extension) for each rendered (tab) or extension that it needs.

Now it wants to lock down these renderers and extensions (before they start doing anything), but it doesn't have sufficient privileges, so it forks of and execs chrome-sandbox (which is suid-root) to do any needed selinux transitioning or other (oom_adj) twiddling needed.

I'm *really* *really* _guessing_ here though, since I'm basing this on what I see in ps and ls output and what I remember reading in LWN.


Maybe giving the chrome binary it's own type (ie. execmem_exec_t -> chrome_exec_t with same privs) and allowing chrome_sandbox_exec_t to write to chrome_exec_t would be enough?

Comment 28 Maciej Żenczykowski 2010-05-12 21:25:08 UTC
It was probably a mistake to put this suggestion at the bottom of the previous comment, so I'll repeat it here:

Maybe giving the chrome binary it's own selinux type (ie. change from the current 'execmem_exec_t' to 'chrome_exec_t' with the same privs) and allowing chrome_sandbox_exec_t to write to chrome_exec_t would be enough?

Comment 29 Tyler Starke 2010-05-12 22:30:56 UTC
This just eats me that Google would try and change Linux instead of working within the set path. Now, I do understand Qt, so I am not a total newb. I picked up oom_adj was an Out of Memory Adjustment, but I had to research that.

This file can be used to adjust the score used to select which process should be killed in an out-of-memory (OOM) situation. The kernel uses this value for a bit-shift operation of the process's oom_score value: valid values are in the range -16 to +15, plus the special value -17, which disables OOM-killing altogether for this process. A positive score increases the likelihood of this process being killed by the OOM-killer; a negative score decreases the likelihood. The default value for this file is 0; a new process inherits its parent's oom_adj setting. A process must be privileged (CAP_SYS_RESOURCE) to update this file. 

(In reply to comment #26)
> Dan: the SUID helper gets run and it sandboxes the Zygote process. The Zygote
> process (which is critical and shouldn't have its oom_adj changed) forks off
> the renderer processes. However, within the sandbox, /proc doesn't exist so we
> can't access it from there.
> 
> I'll make the change to reflect Stephen's suggestions for /selinux, otherwise I
> think this bug is taking more time than is warranted.
> 
> We have to start of 'real' SELinux support behind a #ifdef. If I get around to
> it, I'll do the trick of randomly selecting categories for each renderer.
> 
> 
> Cheers    

Whether or not /proc/ doesn't exist in the sandbox, Qt can pass the location as an object so that it can be accessed. After looking at how oom_adj works, I would rather see Google create a script that can accept CAP_SYS_RESOURCE (thought I have not researched that yet.) than attempt to gain some weird sounding tunnel through.

(In reply to comment #19)
> (In reply to comment #15)
> > I guess then the question is what is the risk of allowing the chrome-sandbox
> > from writing to /proc/PPID/*    
> 
> I wouldn't recommend allowing it.
> 
> First, the granularity is all wrong - you just want to allow this particular
> instance of the sandbox to write to the oom_adj file of the parent.  But the
> SELinux denial is in terms of the security contexts only, and can't distinguish
> this instance of the sandbox from any other, nor the parent from anything else
> running in unconfined_execmem_t, nor oom_adj from any other file in /proc/pid.
> 
> Second, it sounds like the only reason it is being done this way in the first
> place is as a compromise to address limitations introduced by the earlier
> decision to make the process non-dumpable.  And that in turn was motivated by a
> desire to block ptrace among the renderers?  But if they were just run in
> different contexts (e.g. just randomly generate and use a category like sandbox
> or svirt does), ptrace could be blocked based on that without impairing
> dumpability.    

But Stephen said the subprocess is attempting to change the the oom_adj of the parent? Then, again, that is a fault of Googles browser, isn't it? Each and every error occurs when a new tab is opened (apparently .. even when the first tab is opened), so it sounds like the tab, which is a forked process, is not even sending an object back to the parent but is attempting to make changes with it's own privileges. When in fact the forked tabs should be communicating through the parent to the OS.

I don't want to see Chrome receive extra privileges ... I apologize if I am getting on anyone's nerves.

Comment 30 Adam Langley 2010-05-12 22:49:51 UTC
Dan: I think this bug can be closed. You're always welcome to email me if you need any changes from Chrome.

I'm taking myself of the CC now because of the level of noise that this bug has picked up.

Comment 31 cyrushmh 2010-09-26 09:58:30 UTC
[New Thread 7688]
[New Thread 7689]
[New Thread 7698]
[New Thread 7699]
[New Thread 7700]
[New Thread 7795]
[New Thread 7794]
[New Thread 9734]
Core was generated by `/opt/google/chrome/chrome --type=plugin --plugin-path=/opt/google/chrome/libgcf'.
Program terminated with signal 11, Segmentation fault.
#0  0x1180d068 in ?? ()

Thread 8 (Thread 9734):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x008b6d33 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2  0x00fd62a9 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#3  0x00ff87d3 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#4  0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#5  0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 7 (Thread 7794):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00eced96 in poll () from /lib/libc.so.6
No symbol table info available.
#2  0x02a89ce3 in ?? () from /usr/lib/libpulse.so.0
No symbol table info available.
#3  0x02a764ca in pa_mainloop_poll () from /usr/lib/libpulse.so.0
No symbol table info available.
#4  0x02a77d54 in pa_mainloop_iterate () from /usr/lib/libpulse.so.0
No symbol table info available.
#5  0x02a77e34 in pa_mainloop_run () from /usr/lib/libpulse.so.0
No symbol table info available.
#6  0x02a89a84 in ?? () from /usr/lib/libpulse.so.0
No symbol table info available.
#7  0x02ade863 in ?? () from /usr/lib/libpulsecommon-0.9.21.so
No symbol table info available.
#8  0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#9  0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 6 (Thread 7795):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00eced96 in poll () from /lib/libc.so.6
No symbol table info available.
#2  0x036fab66 in ?? () from /lib/libasound.so.2
No symbol table info available.
#3  0x036fad3b in snd_pcm_wait () from /lib/libasound.so.2
No symbol table info available.
#4  0x0137bb83 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#5  0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 5 (Thread 7700):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x008b6d33 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2  0x00fd62a9 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#3  0x00ff87d3 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#4  0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#5  0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 4 (Thread 7699):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x008b698b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2  0x00fd62d7 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#3  0x010db2e5 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#4  0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#5  0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 3 (Thread 7698):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x008b698b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#2  0x00fd62d7 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#3  0x010db2e5 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#4  0x00fd6cd4 in ?? () from /opt/google/chrome/libgcflashplayer.so
No symbol table info available.
#5  0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 2 (Thread 7689):
#0  0x00971424 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00ed54b7 in syscall () from /lib/libc.so.6
No symbol table info available.
#2  0x0876f1be in ?? ()
No symbol table info available.
#3  0x0876ecd9 in ?? ()
No symbol table info available.
#4  0x0876d34b in ?? ()
No symbol table info available.
#5  0x0875a088 in ?? ()
No symbol table info available.
#6  0x087308f4 in ?? ()
No symbol table info available.
#7  0x087309f6 in ?? ()
No symbol table info available.
#8  0x08748fe0 in ?? ()
No symbol table info available.
#9  0x0873b331 in ?? ()
No symbol table info available.
#10 0x008b1f19 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#11 0x00ed9ebe in clone () from /lib/libc.so.6
No symbol table info available.

Thread 1 (Thread 7688):
#0  0x1180d068 in ?? ()
No symbol table info available.
From        To          Syms Read   Shared Object Library
0x00aef4b0  0x00b7fbb8  Yes (*)     /usr/lib/libX11.so.6
0x008c8a40  0x008c9a68  Yes (*)     /lib/libdl.so.2
0x00df52c0  0x00dfb158  Yes (*)     /usr/lib/libXrender.so.1
0x006a38f0  0x006a4768  Yes         /usr/lib/libXss.so.1
0x00d716b0  0x00d7be28  Yes (*)     /usr/lib/libXext.so.6
0x008e68c0  0x008ea928  Yes (*)     /lib/librt.so.1
0x045ae0a0  0x048916c8  Yes (*)     /usr/lib/libgtk-x11-2.0.so.0
0x029b1f10  0x02a19f38  Yes (*)     /usr/lib/libgdk-x11-2.0.so.0
0x002f6480  0x00303ad8  Yes (*)     /usr/lib/libatk-1.0.so.0
0x002732f0  0x00287978  Yes (*)     /usr/lib/libgdk_pixbuf-2.0.so.0
0x003146b0  0x00319b98  Yes (*)     /usr/lib/libpangocairo-1.0.so.0
0x002af240  0x002d1138  Yes (*)     /usr/lib/libpango-1.0.so.0
0x00401020  0x00487928  Yes (*)     /usr/lib/libcairo.so.2
0x00a68ea0  0x00a9e238  Yes (*)     /lib/libgobject-2.0.so.0
0x00ad5bd0  0x00ad6d48  Yes (*)     /lib/libgmodule-2.0.so.0
0x00a5bf30  0x00a5d718  Yes (*)     /lib/libgthread-2.0.so.0
0x00122160  0x001ba2d8  Yes (*)     /lib/libglib-2.0.so.0
0x03105fc0  0x031efc28  Yes (*)     /opt/google/chrome/libnss3.so.1d
0x030c8c90  0x030d5048  Yes (*)     /opt/google/chrome/libnssutil3.so.1d
0x03318bb0  0x03332768  Yes (*)     /opt/google/chrome/libsmime3.so.1d
0x006e2ab0  0x006e3a98  Yes (*)     /opt/google/chrome/libplds4.so.0d
0x030bde40  0x030bf818  Yes (*)     /opt/google/chrome/libplc4.so.0d
0x030877c0  0x030aac78  Yes (*)     /opt/google/chrome/libnspr4.so.0d
0x008b0640  0x008bcdc8  Yes (*)     /lib/libpthread.so.0
0x008cf670  0x008dc298  Yes (*)     /lib/libz.so.1
0x00daff60  0x00dcbcf8  Yes (*)     /usr/lib/libfontconfig.so.1
0x00324340  0x00387788  Yes (*)     /usr/lib/libfreetype.so.6
0x03341e50  0x03375f28  Yes (*)     /usr/lib/libjpeg.so.62
0x00d856f0  0x00da16d8  Yes (*)     /usr/lib/libpng12.so.0
0x02e39f10  0x02e57a28  Yes (*)     /usr/lib/libgconf-2.so.4
0x0339a000  0x033a74a8  Yes (*)     /opt/google/chrome/libbz2.so.1.0
0x036cce00  0x0375f1d8  Yes (*)     /lib/libasound.so.2
0x00d47040  0x00d5fef8  Yes         /lib/libexpat.so.1
0x005b16b0  0x005c33c8  Yes (*)     /usr/lib/libdbus-glib-1.so.2
0x002236a0  0x00252728  Yes (*)     /lib/libdbus-1.so.3
0x02b8f880  0x02bc7078  Yes (*)     /usr/lib/libcups.so.2
0x004b4240  0x00506988  Yes         /lib/libgcrypt.so.11
0x0074eb30  0x007c18c8  Yes (*)     /usr/lib/libstdc++.so.6
0x008884b0  0x008a23a8  Yes (*)     /lib/libm.so.6
0x008f1f90  0x00908818  Yes (*)     /lib/libgcc_s.so.1
0x00e13bf0  0x00f36514  Yes (*)     /lib/libc.so.6
0x00abbe80  0x00aca628  Yes (*)     /usr/lib/libxcb.so.1
0x006e8850  0x00700e6f  Yes (*)     /lib/ld-linux.so.2
0x00269e70  0x0026c3b8  Yes (*)     /usr/lib/libXfixes.so.3
0x00c35d50  0x00cef638  Yes (*)     /lib/libgio-2.0.so.0
0x003cf360  0x003ec798  Yes (*)     /usr/lib/libpangoft2-1.0.so.0
0x00290780  0x00291258  Yes         /usr/lib/libXinerama.so.1
0x00de4780  0x00dee938  Yes (*)     /usr/lib/libXi.so.6
0x00294150  0x00298c38  Yes         /usr/lib/libXrandr.so.2
0x0029ce40  0x002a2418  Yes (*)     /usr/lib/libXcursor.so.1
0x003af890  0x003b0498  Yes (*)     /usr/lib/libXcomposite.so.1
0x003b27c0  0x003b3268  Yes (*)     /usr/lib/libXdamage.so.1
0x0052fb70  0x00587958  Yes (*)     /usr/lib/libpixman-1.so.0
0x02eb8e30  0x02ee0a88  Yes (*)     /usr/lib/libORBit-2.so.0
0x02e703a0  0x02e96b18  Yes (*)     /lib/libgssapi_krb5.so.2
0x02f370d0  0x02fa2c78  Yes (*)     /lib/libkrb5.so.3
0x02f02970  0x02f192c8  Yes (*)     /lib/libk5crypto.so.3
0x006d7e30  0x006d8ba8  Yes (*)     /lib/libcom_err.so.2
0x0323c8a0  0x032b6ed8  Yes (*)     /usr/lib/libgnutls.so.26
0x00607630  0x00607c08  Yes (*)     /lib/libgpg-error.so.0
0x003b7550  0x003bd8f8  Yes (*)     /usr/lib/libavahi-common.so.3
0x033e6950  0x033f01a8  Yes (*)     /usr/lib/libavahi-client.so.3
0x005d58c0  0x005da738  Yes (*)     /lib/libcrypt.so.1
0x00c14a00  0x00c157f8  Yes (*)     /usr/lib/libXau.so.6
0x00a42630  0x00a52298  Yes (*)     /lib/libresolv.so.2
0x00a23230  0x00a34c58  Yes (*)     /lib/libselinux.so.1
0x02c98cc0  0x02c9d198  Yes (*)     /lib/libkrb5support.so.0
0x006dd860  0x006ddfc8  Yes         /lib/libkeyutils.so.1
0x030e2200  0x030eed38  Yes (*)     /usr/lib/libtasn1.so.3
0x0060e980  0x0063d398  Yes (*)     /usr/lib/libfreebl3.so
0x005969b0  0x0059da48  Yes (*)     /lib/libnss_files.so.2
0x00659b30  0x0067de38  Yes (*)     /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so
0x003c30e0  0x003c3a68  Yes (*)     /usr/lib/gtk-2.0/modules/libpk-gtk-module.so
0x00805720  0x00807848  Yes (*)     /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so
0x003c6540  0x003c7aa8  Yes (*)     /usr/lib/libcanberra-gtk.so.0
0x006853c0  0x0068f408  Yes (*)     /usr/lib/libcanberra.so.0
0x034b8720  0x034bd878  Yes (*)     /usr/lib/libvorbisfile.so.3
0x033ae770  0x033c3a08  Yes (*)     /usr/lib/libvorbis.so.0
0x033922f0  0x03394b38  Yes         /usr/lib/libogg.so.0
0x03526610  0x0352f858  Yes         /usr/lib/libtdb.so.1
0x033d9a20  0x033de438  Yes (*)     /usr/lib/libltdl.so.7
0x00fbbf80  0x018d62e8  Yes (*)     /opt/google/chrome/libgcflashplayer.so
0x00816b40  0x008539e8  Yes (*)     /usr/lib/libXt.so.6
0x032df020  0x033047c8  Yes (*)     /usr/lib/libssl3.so
0x02c8e380  0x02c92d28  Yes         /usr/lib/libSM.so.6
0x02ff2530  0x030021f8  Yes         /usr/lib/libICE.so.6
0x005cef00  0x005d0bc8  Yes (*)     /lib/libuuid.so.1
0x00917810  0x0095b2c8  Yes (*)     /usr/lib/libcurl.so.4
0x00973d30  0x00978848  Yes (*)     /lib/libidn.so.11
0x034a9710  0x034b0f28  Yes (*)     /usr/lib/liblber-2.4.so.2
0x03645080  0x03676718  Yes (*)     /usr/lib/libldap-2.4.so.2
0x006a93f0  0x006c5618  Yes (*)     /usr/lib/libssh2.so.1
0x0348f1b0  0x0349f9d8  Yes (*)     /usr/lib/libsasl2.so.2
0x03032e60  0x0306ac98  Yes (*)     /usr/lib/libssl.so.10
0x02cd9e80  0x02dbd798  Yes (*)     /usr/lib/libcrypto.so.10
0x009a6bc0  0x009d2fd8  Yes (*)     /usr/lib/libsoftokn3.so
0x033fbf80  0x0346f9b8  Yes (*)     /usr/lib/libsqlite3.so.0
0x005a2810  0x005a4bd8  Yes (*)     /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
0x02a61000  0x02a90af8  Yes (*)     /usr/lib/libpulse.so.0
0x02aad7c0  0x02ae1008  Yes (*)     /usr/lib/libpulsecommon-0.9.21.so
0x00694ec0  0x00697bd8  Yes (*)     /usr/lib/libXtst.so.6
0x0069bf10  0x006a0008  Yes (*)     /lib/libwrap.so.0
0x01b0b340  0x01b5baa8  Yes (*)     /usr/lib/libsndfile.so.1
0x006cdd80  0x006d0a58  Yes (*)     /usr/lib/libasyncns.so.0
0x0300e0d0  0x0301cc68  Yes (*)     /lib/libnsl.so.1
0x009e9580  0x00a13848  Yes (*)     /usr/lib/libFLAC.so.8
0x01e28b90  0x01e2b068  Yes (*)     /usr/lib/libvorbisenc.so.2
0x005a7440  0x005a8ad8  Yes (*)     /usr/lib/gconv/UTF-16.so
0x01b78390  0x01b79da8  Yes (*)     /usr/lib/gconv/GB18030.so
0x007f7580  0x007f9898  Yes (*)     /usr/lib/gconv/EUC-CN.so
0x00867510  0x00867618  Yes (*)     /usr/lib/gconv/libGB.so
0x007fd950  0x007ffae8  Yes (*)     /usr/lib/gtk-2.0/2.10.0/immodules/im-ibus.so
0x01bb12e0  0x01bd1c38  Yes (*)     /usr/lib/libibus.so.2
0x01becb80  0x01bf9f18  Yes (*)     /usr/lib/gio/modules/libgioremote-volume-monitor.so
0x01c05c00  0x01c10f18  Yes (*)     /usr/lib/libgvfscommon.so.0
0x006d3a00  0x006d4438  Yes (*)     /lib/libutil.so.1
0x01c1c480  0x01c37bf8  Yes (*)     /usr/lib/gio/modules/libgvfsdbus.so
0x01c430a0  0x01c4bfc8  Yes (*)     /lib/libudev.so.0
(*): Shared library is missing debugging information.
$1 = 0x0
No symbol "__glib_assert_msg" in current context.
eax            0x1	1
ecx            0x1180d068	293654632
edx            0x1180d068	293654632
ebx            0x0	0
esp            0x1180d068	0x1180d068
ebp            0x0	0x0
esi            0x0	0
edi            0x0	0
eip            0x1180d068	0x1180d068
eflags         0x210202	[ IF RF ID ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
No function contains program counter for selected frame.
Debuginfo absent: 02387c511bf69dc9612cddb59f150e4bac79a436
Debuginfo absent: 0768378f38047f17d48b9e9f7f151a8394aa9160
Debuginfo absent: 0a9045f1e53836d398bc54a47d3d6a8a34eba1e8
Debuginfo absent: 0e84498ba9ebc54d908d90604a20ed780efc4f63
Debuginfo absent: 1072a751dd6ce8ecf06707710faac5b32836e361
Debuginfo absent: 18d7d7067cac808fe4dbf2e790c81dffc3b54e85
Debuginfo absent: 19809ca64911a23e3b3eda4f757e6ac490421aea
Debuginfo absent: 24ded4515cb2703c2966e3f8d762f8449fba9569
Debuginfo absent: 25dbc55a617ca87b146f5c50a8867b56c725081c
Debuginfo absent: 2618a6cf5690f708ca7ac840f136eb7aeeb0eea6
Debuginfo absent: 2646de4387ff5c1e017ee11c375c842f2651293e
Debuginfo absent: 2810dd57201dd4156f9723a5b6b346f461403307
Debuginfo absent: 2d460a2adb813bffeb975c623b4ec2cfafabd2b5
Debuginfo absent: 2d70063139f2c1c51a878073584b6796e95177e6
Debuginfo absent: 2ef49f10785af6a1108ae06eea0b371107730e2c
Debuginfo absent: 360e9b55dbe2bc28991d91c70377ec8ccd885ea7
Debuginfo absent: 3833c2a579f057bb859a8e954167eca75e0de6b6
Debuginfo absent: 3871edc037d3c657488adc1b5412e6f0575c973c
Debuginfo absent: 39d0599c44a3330d3e0feb466bda73256acb46fa
Debuginfo absent: 39ea914bbf6e8cd106c45fc84c7c318520f75ad9
Debuginfo absent: 3b58fe3361986b948b8f2e67c52894014ab81aeb
Debuginfo absent: 3d57253169cd92a592a9e9d142f5c4ec7758b446
Debuginfo absent: 447c85bc6ed60cdf8b67dd0bb911b873b1bf5831
Debuginfo absent: 44fff6ff9994506a4f2321aa4edfb06c0879e7fb
Debuginfo absent: 493299b14aee2974de72aaa32167c8ba8d9a3b45
Debuginfo absent: 49570b839e1c81aa23a1f67853a580ae15b6f6d2
Debuginfo absent: 4a41b45333067dc9d6f6aac6b6425ec8c58f1473
Debuginfo absent: 4aae34e6b63bccae0ca874e5901563c094020b47
Debuginfo absent: 4bf617ba297eaa743836031bf227f0c3cd9c5749
Debuginfo absent: 4ca9769d208e496e4eb855339fbfad8ef46b79e0
Debuginfo absent: 4d891f47399896f1e982c94c9b3017c5b71ba6a6
Debuginfo absent: 4dd7e58ead89156c9745fd4a575dcc27e348ad42
Debuginfo absent: 4ea3cc3f38faaf8821fc7361f45add896e94be7f
Debuginfo absent: 4eaf27c1985602052fc2054c04d76564758777cf
Debuginfo absent: 53c91d5c59eef4ff5fd29be9f88db3252aa02e37
Debuginfo absent: 53ea712d27c8a4401e32c0f8078da7774bb434d5
Debuginfo absent: 566d91601782324bd8ca0c2bb1cd5578016376d3
Debuginfo absent: 56e7c2c5b3daebd2e16652298cd16e82afcb4411
Debuginfo absent: 585cacadadae2413253c56b9cd900dd20fd9f628
Debuginfo absent: 5f06b38be49ad5b1a9905159a63426c05e719bd1
Debuginfo absent: 698410ac6c42e852bf4fca9bcbedbb17ded50707
Debuginfo absent: 6a37ce62c96cf5cb58256c90a57b0d0716c3571f
Debuginfo absent: 72dcfe6feb090980a905966e2c2b443d4ce16570
Debuginfo absent: 72f64ad9b6d79fab13189b7de92252bc9c4f47a2
Debuginfo absent: 7b6bdc37b61b6eca81b25a64d9f110008a1a2913
Debuginfo absent: 7be1bd5c25732bcf16acc9fbeab2ef6e0acea88f
Debuginfo absent: 7d6adb4652e7c95e3e87758ecd3bac46a79f5781
Debuginfo absent: 803dcf446ddfca6bc21d0080afa1ecdbee109365
Debuginfo absent: 833cefc956955eb38c7480f97484af29170870c0
Debuginfo absent: 84f5d6af10e941cc566d4dfee3275f0dc7772dee
Debuginfo absent: 8514f084a1026b039c77ecf8e52d1f2d00e21e5f
Debuginfo absent: 854b43661b864b677eb6726609fcdfeb78536d15
Debuginfo absent: 8981a35be6b02de75b5f1bcd5b0871ff85ba6eb1
Debuginfo absent: 89ddce98f457cf0206c3df0e3c8d9ed3f2088b34
Debuginfo absent: 8a19166ca2e8042e7130cbe507dd33d6d03e5fca
Debuginfo absent: 8aa2d4a3559a9d8411927ff1659682c390149aa0
Debuginfo absent: 8d50e6f99af6d8c6e8750995a618b479f8716508
Debuginfo absent: 91158a001773ed732a6bfc8859dc935d97eed2f0
Debuginfo absent: 9239eaaf595f82fcc2b59bdb491cbab174f6ab4c
Debuginfo absent: 980679b6bdedffd505f75a000da9e8772d90dd16
Debuginfo absent: 98238fa6c859c77073b285cd52976f8ea341097c
Debuginfo absent: 9c823ec9bfe31a1ed1b2a88213d9797113f74ec0
Debuginfo absent: a150dc301065d9027302b4dcb62c665c6c6d8829
Debuginfo absent: a244f90a262e0069120df73d8b97a3b6ddb6a3b8
Debuginfo absent: a3732532c5f5edecfb4bfac37893431f74a518ae
Debuginfo absent: a5e465990cbff18a8adf56d59fb45b72ab090714
Debuginfo absent: aa1edb076ddfb1f5a96308a6f73a375acfaf1c72
Debuginfo absent: ab03d46dea6fa701571a22f3944715788064b41c
Debuginfo absent: ac19cea9410a15efc67ffdf89d9a5111349bb57b
Debuginfo absent: ac27405845153e582587e8eccb596a6f25a01daa
Debuginfo absent: af0add81509b4e35970dfae65d9187762e0e5e44
Debuginfo absent: b00a4547b125ec7fc5983247b6065cf70b173be9
Debuginfo absent: b0e5e00c8117beb1e19b32a8f8a584ddd9a6491d
Debuginfo absent: b212433d6a1b297da241e4942419149bbc01cafd
Debuginfo absent: b4349180465743c4555f8e24437c4ab5d25b3f78
Debuginfo absent: be76f9e2ecac6f6c8a0e925e71fa1d3057f127fe
Debuginfo absent: c9dae628809e61c856c6b1d8417d52d0ff957b5d
Debuginfo absent: ccca7b7752e98f6ddc3a8302ec897d1f230f325a
Debuginfo absent: d1008f0daeb3e025567c535ce411b7b666047c80
Debuginfo absent: d10e4b7006f478c480f711bd264c8db820546a53
Debuginfo absent: d3a4a4f4202345cfb81c47afc4f5eef707f660a4
Debuginfo absent: d3ed02b9d190bf5ac5476897806e531a28cd5f52
Debuginfo absent: d420b3ac9d4f138e2b9813db10bd568174f9d9e4
Debuginfo absent: da39f91b65bdd00b6bf2290ffdd90e93ed76885a
Debuginfo absent: dad0d5881afb24f116605c2ebe5f42861aa454a1
Debuginfo absent: db2f3912f9316dffe0c572f1fa4b471a1a077b38
Debuginfo absent: db688579022abc43a2e27c1e850a08ace452adf8
Debuginfo absent: dcb18b1be38a6eb757e064b63dac6db24d0f6850
Debuginfo absent: dd25bde637b0f8963724bcabb962baf74e7360d7
Debuginfo absent: dd4567e40d4c5967e2156aaf8d0ba8208f4daef2
Debuginfo absent: de454c0a26adc89b069df877046148971cc97983
Debuginfo absent: deb312a7cb499731779149c9aeb9b16416e2034a
Debuginfo absent: dec477b7e69e33e81e76aa8f2201a07ec8186973
Debuginfo absent: df5dd7f20306816336f9d0f2cfc477f74a9fdb41
Debuginfo absent: e072877b59522a02303cab26412f83dba4e82753
Debuginfo absent: e11c2b1cbbececd0c4bfd0d6397074a341b503f6
Debuginfo absent: e4076b8a7e979a29269b005ec846a3176153eab2
Debuginfo absent: e4348ff2068b1b03263454f4d80bd4ac7068b1b3
Debuginfo absent: eb7c12ab3beeaf7bdbb5e9f479405fdb5cec6c70
Debuginfo absent: ee92a12ce1a6f36705b9b01dc3bf9ff3098a33e3
Debuginfo absent: eef2645df179a6eeaefc243aad5c223cc8524ff5
Debuginfo absent: ef2dc4c8a43bf476b4866adad4df4c421c5f9e14
Debuginfo absent: f403dff3727cbe36c323a3ce959b35f829dff9e0
Debuginfo absent: f977d45a4ab80ec37972bf0777e8bd7064441be3
Debuginfo absent: fbedf91fea5ffa5772f83a83d7a132c0f81939d2
Debuginfo absent: fe4ff4c8d2523eed5275a2c2e311a191905bbc6d
Debuginfo absent: ff0c67b4f33aac0cc43f9b704ea8c26ef2545fc7

Comment 32 Daniel Walsh 2010-09-26 10:07:35 UTC
Miroslav could you back port the F14 chrome-sandbox policy to F12/F13

Comment 33 Miroslav Grepl 2010-10-01 06:38:05 UTC
Fixed in selinux-policy-3.6.32-123.fc12

Comment 34 Fedora Update System 2010-10-01 08:48:20 UTC
selinux-policy-3.6.32-123.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-123.fc12

Comment 35 Fedora Update System 2010-10-05 09:32:52 UTC
selinux-policy-3.6.32-123.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-123.fc12

Comment 36 Fedora Update System 2010-10-14 06:32:56 UTC
selinux-policy-3.6.32-123.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.