SELinux Interfering With sss_cache

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
4
down vote

favorite












System:



  • HP Pavilion Power Laptop 15-cb0xx

  • Intel i7-7700HQ w/ integrated graphics enabled (can't be turned off in bios)

  • Fedora 28

  • NVIDIA GTX 1050 (mobile)

I used the dnfdragora GUI to update about 119 packages (I forgot to update for a while :/). At some point I got a notification from SELinux:



SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/


I dug through /var/log/messages and /var/log/audit/audit.log and found the same stuff that SELinux told me.



After all this went down, I noticed things were going kind of slowly, so I rebooted. The reboot was slower, particularly obvious when the Fedora logo was loading, when the login GUI was loading, and when the desktop was loading. An additional reboot did not fix anything.



From looking at the manpage for sss_cache I get the gist of what it does, and that it works with the System Security Services Daemon (SSSD).



This is what the SELinux dialog box is telling me:
enter image description here



I understand that this will notify the maintainers of a potential bug, and the policy changes will prevent SELinux from alerting on sss_cache in the future. I do not know anything about SELinux other than it provides added/configurable security additions to a Linux system. However, I still do not understand why this happened, or if there are other, potentially better, solutions. Nor is it clear to me if this will clear up the slowdown issues I noticed.



Can anyone tell me:



  1. Why this might have happened? I can guess that SELinux considers anything associated with SSSD as very important to protect, but why is it not aware of a utility meant to work with SSSD?

  2. Should I just report the bug and create the local policy module, or something else?

  3. Should I undo the transaction that led to all this and update the packages in smaller groups? Would it even undo the problem?

  4. Could this have caused the slowdown issues I noted above? I know from working with VMs (specifically expanding storage space in VirtualBox) that leaving an old entry /etc/fstab can slow down boot because the system is looking for something that doesn't exist. Is something similar going on here?

I am loath to just do what the words on the screen say without additional information. I don't want to put a band-aid on a bomb crater without realizing it.



(Additional Information as Requested):
I should have stated: /var/lib/sss/db/ is a directory.



ls -Z /var/lib/sss/ output for db/: system_u:object_r:sssd_var_lib_t:s0



Excerpt from audit.log (includes a potentially unrelated line sandwiched between two relevant ones):



type=AVC msg=audit(1543865969.237:241): avc: denied write for pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc: denied write for pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0


Output of ls -Z /usr/sbin/sss_cache (location found via which sss_cache):



system_u:object_r:bin_t:s0


Turns out the "details" window had a lot of info:
enter image description here










share|improve this question























  • Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log?
    – danblack
    Dec 4 at 2:31










  • @user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :(
    – Ungeheuer
    Dec 4 at 3:00










  • @danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives.
    – Ungeheuer
    Dec 4 at 3:43










  • Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux .
    – Panther
    Dec 4 at 6:58










  • @Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment.
    – Ungeheuer
    Dec 4 at 13:17














up vote
4
down vote

favorite












System:



  • HP Pavilion Power Laptop 15-cb0xx

  • Intel i7-7700HQ w/ integrated graphics enabled (can't be turned off in bios)

  • Fedora 28

  • NVIDIA GTX 1050 (mobile)

I used the dnfdragora GUI to update about 119 packages (I forgot to update for a while :/). At some point I got a notification from SELinux:



SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/


I dug through /var/log/messages and /var/log/audit/audit.log and found the same stuff that SELinux told me.



After all this went down, I noticed things were going kind of slowly, so I rebooted. The reboot was slower, particularly obvious when the Fedora logo was loading, when the login GUI was loading, and when the desktop was loading. An additional reboot did not fix anything.



From looking at the manpage for sss_cache I get the gist of what it does, and that it works with the System Security Services Daemon (SSSD).



This is what the SELinux dialog box is telling me:
enter image description here



I understand that this will notify the maintainers of a potential bug, and the policy changes will prevent SELinux from alerting on sss_cache in the future. I do not know anything about SELinux other than it provides added/configurable security additions to a Linux system. However, I still do not understand why this happened, or if there are other, potentially better, solutions. Nor is it clear to me if this will clear up the slowdown issues I noticed.



Can anyone tell me:



  1. Why this might have happened? I can guess that SELinux considers anything associated with SSSD as very important to protect, but why is it not aware of a utility meant to work with SSSD?

  2. Should I just report the bug and create the local policy module, or something else?

  3. Should I undo the transaction that led to all this and update the packages in smaller groups? Would it even undo the problem?

  4. Could this have caused the slowdown issues I noted above? I know from working with VMs (specifically expanding storage space in VirtualBox) that leaving an old entry /etc/fstab can slow down boot because the system is looking for something that doesn't exist. Is something similar going on here?

I am loath to just do what the words on the screen say without additional information. I don't want to put a band-aid on a bomb crater without realizing it.



(Additional Information as Requested):
I should have stated: /var/lib/sss/db/ is a directory.



ls -Z /var/lib/sss/ output for db/: system_u:object_r:sssd_var_lib_t:s0



Excerpt from audit.log (includes a potentially unrelated line sandwiched between two relevant ones):



type=AVC msg=audit(1543865969.237:241): avc: denied write for pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc: denied write for pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0


Output of ls -Z /usr/sbin/sss_cache (location found via which sss_cache):



system_u:object_r:bin_t:s0


Turns out the "details" window had a lot of info:
enter image description here










share|improve this question























  • Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log?
    – danblack
    Dec 4 at 2:31










  • @user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :(
    – Ungeheuer
    Dec 4 at 3:00










  • @danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives.
    – Ungeheuer
    Dec 4 at 3:43










  • Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux .
    – Panther
    Dec 4 at 6:58










  • @Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment.
    – Ungeheuer
    Dec 4 at 13:17












up vote
4
down vote

favorite









up vote
4
down vote

favorite











System:



  • HP Pavilion Power Laptop 15-cb0xx

  • Intel i7-7700HQ w/ integrated graphics enabled (can't be turned off in bios)

  • Fedora 28

  • NVIDIA GTX 1050 (mobile)

I used the dnfdragora GUI to update about 119 packages (I forgot to update for a while :/). At some point I got a notification from SELinux:



SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/


I dug through /var/log/messages and /var/log/audit/audit.log and found the same stuff that SELinux told me.



After all this went down, I noticed things were going kind of slowly, so I rebooted. The reboot was slower, particularly obvious when the Fedora logo was loading, when the login GUI was loading, and when the desktop was loading. An additional reboot did not fix anything.



From looking at the manpage for sss_cache I get the gist of what it does, and that it works with the System Security Services Daemon (SSSD).



This is what the SELinux dialog box is telling me:
enter image description here



I understand that this will notify the maintainers of a potential bug, and the policy changes will prevent SELinux from alerting on sss_cache in the future. I do not know anything about SELinux other than it provides added/configurable security additions to a Linux system. However, I still do not understand why this happened, or if there are other, potentially better, solutions. Nor is it clear to me if this will clear up the slowdown issues I noticed.



Can anyone tell me:



  1. Why this might have happened? I can guess that SELinux considers anything associated with SSSD as very important to protect, but why is it not aware of a utility meant to work with SSSD?

  2. Should I just report the bug and create the local policy module, or something else?

  3. Should I undo the transaction that led to all this and update the packages in smaller groups? Would it even undo the problem?

  4. Could this have caused the slowdown issues I noted above? I know from working with VMs (specifically expanding storage space in VirtualBox) that leaving an old entry /etc/fstab can slow down boot because the system is looking for something that doesn't exist. Is something similar going on here?

I am loath to just do what the words on the screen say without additional information. I don't want to put a band-aid on a bomb crater without realizing it.



(Additional Information as Requested):
I should have stated: /var/lib/sss/db/ is a directory.



ls -Z /var/lib/sss/ output for db/: system_u:object_r:sssd_var_lib_t:s0



Excerpt from audit.log (includes a potentially unrelated line sandwiched between two relevant ones):



type=AVC msg=audit(1543865969.237:241): avc: denied write for pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc: denied write for pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0


Output of ls -Z /usr/sbin/sss_cache (location found via which sss_cache):



system_u:object_r:bin_t:s0


Turns out the "details" window had a lot of info:
enter image description here










share|improve this question















System:



  • HP Pavilion Power Laptop 15-cb0xx

  • Intel i7-7700HQ w/ integrated graphics enabled (can't be turned off in bios)

  • Fedora 28

  • NVIDIA GTX 1050 (mobile)

I used the dnfdragora GUI to update about 119 packages (I forgot to update for a while :/). At some point I got a notification from SELinux:



SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/


I dug through /var/log/messages and /var/log/audit/audit.log and found the same stuff that SELinux told me.



After all this went down, I noticed things were going kind of slowly, so I rebooted. The reboot was slower, particularly obvious when the Fedora logo was loading, when the login GUI was loading, and when the desktop was loading. An additional reboot did not fix anything.



From looking at the manpage for sss_cache I get the gist of what it does, and that it works with the System Security Services Daemon (SSSD).



This is what the SELinux dialog box is telling me:
enter image description here



I understand that this will notify the maintainers of a potential bug, and the policy changes will prevent SELinux from alerting on sss_cache in the future. I do not know anything about SELinux other than it provides added/configurable security additions to a Linux system. However, I still do not understand why this happened, or if there are other, potentially better, solutions. Nor is it clear to me if this will clear up the slowdown issues I noticed.



Can anyone tell me:



  1. Why this might have happened? I can guess that SELinux considers anything associated with SSSD as very important to protect, but why is it not aware of a utility meant to work with SSSD?

  2. Should I just report the bug and create the local policy module, or something else?

  3. Should I undo the transaction that led to all this and update the packages in smaller groups? Would it even undo the problem?

  4. Could this have caused the slowdown issues I noted above? I know from working with VMs (specifically expanding storage space in VirtualBox) that leaving an old entry /etc/fstab can slow down boot because the system is looking for something that doesn't exist. Is something similar going on here?

I am loath to just do what the words on the screen say without additional information. I don't want to put a band-aid on a bomb crater without realizing it.



(Additional Information as Requested):
I should have stated: /var/lib/sss/db/ is a directory.



ls -Z /var/lib/sss/ output for db/: system_u:object_r:sssd_var_lib_t:s0



Excerpt from audit.log (includes a potentially unrelated line sandwiched between two relevant ones):



type=AVC msg=audit(1543865969.237:241): avc: denied write for pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc: denied write for pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0


Output of ls -Z /usr/sbin/sss_cache (location found via which sss_cache):



system_u:object_r:bin_t:s0


Turns out the "details" window had a lot of info:
enter image description here







fedora rhel selinux sssd






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 9 at 14:31









Jeff Schaller

37.6k1052121




37.6k1052121










asked Dec 4 at 1:03









Ungeheuer

1306




1306











  • Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log?
    – danblack
    Dec 4 at 2:31










  • @user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :(
    – Ungeheuer
    Dec 4 at 3:00










  • @danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives.
    – Ungeheuer
    Dec 4 at 3:43










  • Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux .
    – Panther
    Dec 4 at 6:58










  • @Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment.
    – Ungeheuer
    Dec 4 at 13:17
















  • Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log?
    – danblack
    Dec 4 at 2:31










  • @user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :(
    – Ungeheuer
    Dec 4 at 3:00










  • @danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives.
    – Ungeheuer
    Dec 4 at 3:43










  • Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux .
    – Panther
    Dec 4 at 6:58










  • @Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment.
    – Ungeheuer
    Dec 4 at 13:17















Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log?
– danblack
Dec 4 at 2:31




Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log?
– danblack
Dec 4 at 2:31












@user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :(
– Ungeheuer
Dec 4 at 3:00




@user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :(
– Ungeheuer
Dec 4 at 3:00












@danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives.
– Ungeheuer
Dec 4 at 3:43




@danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives.
– Ungeheuer
Dec 4 at 3:43












Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux .
– Panther
Dec 4 at 6:58




Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux .
– Panther
Dec 4 at 6:58












@Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment.
– Ungeheuer
Dec 4 at 13:17




@Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment.
– Ungeheuer
Dec 4 at 13:17










1 Answer
1






active

oldest

votes

















up vote
5
down vote



accepted










Looks like a bug in Fedora's SELinux policy.



Before the fix is released, you can use audit2allow generated policy or the policy in the bug report to allow access.






share|improve this answer
















  • 1




    I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
    – Ungeheuer
    Dec 4 at 13:15







  • 1




    @Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
    – mattdm
    Dec 5 at 14:43










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485799%2fselinux-interfering-with-sss-cache%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote



accepted










Looks like a bug in Fedora's SELinux policy.



Before the fix is released, you can use audit2allow generated policy or the policy in the bug report to allow access.






share|improve this answer
















  • 1




    I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
    – Ungeheuer
    Dec 4 at 13:15







  • 1




    @Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
    – mattdm
    Dec 5 at 14:43














up vote
5
down vote



accepted










Looks like a bug in Fedora's SELinux policy.



Before the fix is released, you can use audit2allow generated policy or the policy in the bug report to allow access.






share|improve this answer
















  • 1




    I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
    – Ungeheuer
    Dec 4 at 13:15







  • 1




    @Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
    – mattdm
    Dec 5 at 14:43












up vote
5
down vote



accepted







up vote
5
down vote



accepted






Looks like a bug in Fedora's SELinux policy.



Before the fix is released, you can use audit2allow generated policy or the policy in the bug report to allow access.






share|improve this answer












Looks like a bug in Fedora's SELinux policy.



Before the fix is released, you can use audit2allow generated policy or the policy in the bug report to allow access.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 4 at 8:37









sebasth

8,05331846




8,05331846







  • 1




    I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
    – Ungeheuer
    Dec 4 at 13:15







  • 1




    @Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
    – mattdm
    Dec 5 at 14:43












  • 1




    I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
    – Ungeheuer
    Dec 4 at 13:15







  • 1




    @Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
    – mattdm
    Dec 5 at 14:43







1




1




I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
– Ungeheuer
Dec 4 at 13:15





I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report?
– Ungeheuer
Dec 4 at 13:15





1




1




@Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
– mattdm
Dec 5 at 14:43




@Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix.
– mattdm
Dec 5 at 14:43

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485799%2fselinux-interfering-with-sss-cache%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?