Description of problem: SELinux is preventing /usr/libexec/goa-daemon from 'write' accesses on the key . ***** Plugin catchall (100. confidence) suggests ************************** If vous pensez que goa-daemon devrait être autorisé à accéder write sur key par défaut. Then vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Do autoriser cet accès pour le moment en exécutant : # grep goa-daemon /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:system_r:init_t:s0 Target Objects [ key ] Source goa-daemon Source Path /usr/libexec/goa-daemon Port <Inconnu> Host (removed) Source RPM Packages gnome-online-accounts-3.9.91-1.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-80.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.12.0-0.rc0.git26.1.fc21.x86_64 #1 SMP Sun Sep 15 12:59:22 UTC 2013 x86_64 x86_64 Alert Count 2 First Seen 2013-09-16 17:08:10 CEST Last Seen 2013-09-16 17:08:10 CEST Local ID 2c7e6c88-18c1-4aac-847d-88f8ba7d31d9 Raw Audit Messages type=AVC msg=audit(1379344090.921:129): avc: denied { write } for pid=1942 comm="pool" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=key type=SYSCALL msg=audit(1379344090.921:129): arch=x86_64 syscall=add_key success=no exit=EACCES a0=300928b6c3 a1=300928b6e8 a2=0 a3=0 items=0 ppid=1 pid=1942 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 ses=4294967295 tty=(none) comm=pool exe=/usr/libexec/goa-daemon subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: goa-daemon,xdm_t,init_t,key,write Additional info: reporter: libreport-2.1.7 hashmarkername: setroubleshoot kernel: 3.12.0-0.rc0.git26.1.fc21.x86_64 type: libreport
I have no clue what is going on here. The login program is running goe-daemon which is attempting to write to a key ring owned by systemd?
Not sure but i think this might be related to: "kerberos caching tickets in keys" Do you by chance use kerberos?
No I don't I collect rawhide avcs, I don't claim to understand them :(
Added the guys working on this to see if they have an idea.