Yes some how this got mislabeled.
On 10/27/2014 02:50 PM, Gian Luca Ortelli wrote:
Yes, I ran the restorecon command as you described it
-v ~/.pki') and things were fine again. So I guess my .pki settings
were wrongly changed at some point in the past, right?
I'll keep the setsebool method for the next time chrome breaks, I'm
afraid in a few updates.
On Mon, Oct 27, 2014 at 4:39 PM, Daniel J Walsh <dwalsh(a)redhat.com
Did you run the restorecon command?
It looks like chrome is allowed to read files labeled home_cert_t
but might be blocked form other types.
You could also turn off the chrome security using a boolean
setsebool -P unconfined_chrome_sandbox_transition 1
Which would do the equivalent of what you did in relabelling the
executable to bin_t.
On 10/27/2014 04:07 AM, Gian Luca Ortelli wrote:
> my original fix was more coarse grained than this: I set the type
> of the chrome-sandbox to the generic SELinux executable (was it
> Anyway, I tried your suggestion (a chrome update broke my fix
> several days ago, and I was back to 'setenforce 0' mode) and it
> also solves the problem.
> Any ideas on why I don't get an explicit error message? Something
> like 'selinux is preventing chrome-sandbox from accessing .pki'?
> Or is the problem too indirect for selinux to figure out what's
> going wrong exactly?
> Kind regards,
> Gianluca Ortelli
> On Fri, Oct 24, 2014 at 7:22 PM, Daniel J Walsh
> <dwalsh(a)redhat.com <mailto:firstname.lastname@example.org>> wrote:
> On 10/23/2014 02:28 AM, Gian Luca Ortelli wrote:
>> I recently had to do some selinux tuning to have chrome
>> correctly start on my fedora 20 box. I googled around and
>> eventually found the correct type to apply to the chrome
>> executable in order to make it work.
>> So the problem is solved, but the error messages that I got
>> were much less informative than I expected. After
>> watching https://www.youtube.com/watch?v=MxjenQ31b70
>> selinux configuration, I was expecting messages in a format
>> like "selinux is preventing X from access on directoy Y",
>> but instead...
>> 'journal -f' provided nothing useful; 'tail -f
>> /var/log/audit/audit.log' showed a couple of log lines which
>> actually mentioned chrome, but in too generic a manner (see
>> type=SYSCALL msg=audit(1413532031.170:387): arch=c000003e
>> syscall=56 success=yes exit=2394 a0=60000011 a1=0 a2=0 a3=0
>> items=0 ppid=2382 pid=2393 auid=1000 uid=1000 gid=1000
>> euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000
>> tty=(none) ses=1 comm="chrome-sandbox"
>> type=PROCTITLE msg=audit(1413532031.170:387):
>> type=ANOM_ABEND msg=audit(1413532031.195:388): auid=1000
>> uid=1000 gid=1000 ses=1
>> pid=2394 comm="chrome"
>> Before I fixed the problem, launching google-chrome from
>> command line resulted in an error message about the
>> impossibility of creating directory .pki/nssdb in my home.
>> No mention of this directory name in the audit.
>> And to finish, the SELinux troubleshooting tool didn't show
>> anything at all.
>> Why don't I see a richer diagnostics? Am I missing some
>> Kind regards,
>> Gianluca Ortelli
>> selinux mailing list
> What exactly did you do to fix the problem? Did you have to
> fix the labels on .pki? restorecon -R -v ~/.pki
> selinux mailing list
> selinux(a)lists.fedoraproject.org <mailto:email@example.com>
selinux mailing list