Same message on x86_64 with Fedora-Workstation-Live-x86_64-24_Beta-1.4.iso.

What is accounts-daemon attempting to write into the /root directory?

I don't know, how can I find out?

Please, check comment 2.

Thank you.

Still happens during startup before gdm appears with the most recent nightly, Fedora-Workstation-Live-x86_64-24-20160528.n.0.iso

selinux-policy-3.13.1-185.fc24.noarch
accountsservice-0.6.40-3.fc24.x86_64

Proposed as a Blocker for 24-final by Fedora user chrismurphy using the blocker tracking app because:

 There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop.

problem is gvfs creates ~/.cache at startup if XDG_RUNTIME_DIR isn't set.

accountsservice obviously doesn't need gvfs, so I pushed a change to disable gvfs.

accountsservice-0.6.40-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-550dcbaa52

accountsservice-0.6.40-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-550dcbaa52

Chris: did you actually see a *notification* for this? I just tested with the 2016-05-31 nightly Workstation live, and if I run sealert I do see the AVC, but I did not get a desktop notification for it. The criterion explicitly talks about "denial notifications or crash notifications" for a reason - it is a polish criterion; the reason for the criterion is that it looks bad if we ship an image which tells the user something's wrong as soon as it starts up. So it's only really a release blocker if there's a *notification*.

As I didn't see one in my test, I'd vote -1 blocker / +1 FE, but I'll change that vote if people say they see notifications (as the criterion says, "on boot of or during installation from a release-blocking live image, or at first login after a default install").

Confidence in seeing a notification in gnome-shell is low.

I have also seen this in my sealert history but I have never seen it as a notification, so I'm -1 blocker +1 FE.

*** Bug 1319459 has been marked as a duplicate of this bug. ***

I've been doing release validation testing against all the F24 spins and I hit this bug lots of times during the last 2/3 months.

I'm pretty sure I have never seen a desktop notification for it (and that's why I had not proposed it).

So... I'm -1 blocker and +1 FE.

Odd. I wonder why no notification on it? Is the applet not notifying on _any_ avcs / not working?

Given the no notifications, I would be -1 blocker / +1 FE, but it would be good to know if the alerts are completely broken or it's just not mentioning anything about this specific avc for some reason.

(In reply to Kevin Fenzi from comment #15)
> Odd. I wonder why no notification on it? Is the applet not notifying on
> _any_ avcs / not working?

Correct, all notifications from sealert have been broken for some time now, at least in F24 and I think perhaps also in F23. So -1 blocker, +1 FE.

yikes, that's not good. That in itself could arguably be a blocker as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." and/or "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.", and I suppose if we *fixed* that, then this and other AVCs may suddenly start appearing as notifications and thus become blockers...

Let's not fix notifications this late in the game; the app withstands a basic functionality test unless you happen to have prior knowledge that it is supposed to provide notifications. And I see two other AVCs in mine, so I guess we might wind up with even more blockers, indeed, if that's fixed.

-1 blocker

The avc denial is not visible as a DE notification. Plus the denial has no consequences insofar as this user is aware, it just seems like journal noise.

(In reply to Giulio 'juliuxpigface' from comment #14)
Description of problem:
SELinux is preventing accounts-daemon from 'write' accesses on the directory /root.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that accounts-daemon should be allowed write access on the root directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep accounts-daemon /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:accountsd_t:s0
Target Context                system_u:object_r:admin_home_t:s0
Target Objects                /root [ dir ]
Source                        accounts-daemon
Source Path                   accounts-daemon
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           filesystem-3.2-37.fc24.x86_64
Policy RPM                    selinux-policy-3.13.1-179.fc24.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.5.0-0.rc7.git0.2.fc24.x86_64 #1
                              SMP Tue Mar 8 02:20:08 UTC 2016 x86_64 x86_64
Alert Count                   1
First Seen                    2016-03-20 11:09:19 CET
Last Seen                     2016-03-20 11:09:19 CET
Local ID                      ece385de-d2dd-4c0d-8747-6c6d8d5b1f52

Raw Audit Messages
type=AVC msg=audit(1458468559.774:106): avc:  denied  { write } for  pid=939 comm="accounts-daemon" name="root" dev="dm-0" ino=262146 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir permissive=0


Hash: accounts-daemon,accountsd_t,admin_home_t,dir,write

Version-Release number of selected component:
selinux-policy-3.13.1-179.fc24.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.5.0-0.rc7.git0.2.fc24.x86_64
type:           libreport

This bug does not appear to meet the blocker criteria as there is no notification of the bug upon initial boot, and because of this, I vote -1 blocker. See the criteria here: [1]

"There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop."

[1] https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#SELinux_and_crash_notifications

Description of problem:
SELinux alert reported by SELinux Troubleshooter after booting from Fedora-Workstation-Live-x86_64-24-20160604.n.0 image.

Version-Release number of selected component:
selinux-policy-3.13.1-190.fc24.noarch

Additional info:
reporter:       libreport-2.7.1
hashmarkername: setroubleshoot
kernel:         4.5.5-300.fc24.x86_64
reproducible:   Not sure how to reproduce the problem
type:           libreport

(In reply to Geoffrey Marr from comment #21)
It appears to me that comment 22 refutes the point made in comment 21 and proves that bug 1331926 is indeed a release-blocking bug.

This bug was discussed at the 2016-06-06 blocker review meeting [1] and determined to be a RejectedBlocker as there is no automatic desktop notification displayed when this bug occurs and there are no significant practical consequences to this bug.


[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-06-06/f24-blocker-review.2016-06-06-16.00.txt

Description of problem:
Installed F24 beta, then did a DNF update to the latest bits.  During the dnf update, I noticed two SELinux alerts.  This is one of the two.

Version-Release number of selected component:
selinux-policy-3.13.1-182.fc24.noarch

Additional info:
reporter:       libreport-2.7.1
hashmarkername: setroubleshoot
kernel:         4.5.2-302.fc24.x86_64
reproducible:   Not sure how to reproduce the problem
type:           libreport

Description of problem:
To reproduce
1 - Fresh Install of f24 beta from fedora official website (did not produce such notification)
2- dnf upgrade to get the latest bits
 => notification of two errors with SELinux

	a_ This one says "SELinux is preventing accounts-daemon from write access on the directory root."
	b_ Another one says "SELinux is preventing (uetoothd) from mounton access on the directory /etc."

{Note : the other error notification says "uetoothd" not sure if this is a mispelling of bluetoothd?}

Version-Release number of selected component:
selinux-policy-3.13.1-182.fc24.noarch

Additional info:
reporter:       libreport-2.7.1
hashmarkername: setroubleshoot
kernel:         4.5.2-302.fc24.x86_64
reproducible:   Not sure how to reproduce the problem
type:           libreport

I wish we understood why some users are getting SELinux notifications, and others are not.

(In reply to Michael Catanzaro from comment #27)
I am fairly sure that the author of comment 26 has 1) -not- relabeled the file system after updating his system, 2) -not- deleted all pending SELinux alerts (probably stemming from the Beta state of his system before updating), and 3) -not- rebooted the system afterward which is the safest approach that SELinux alerts properly reflect the current policy.

If he had used a recent image like Fedora-Workstation-Live-x86_64-24-1.2.iso  instead of the completely outdated Beta image chances would have been good that he had had nothing to report; at least as far as the accountsservice alert is concerned.

I am currently using Fedora 24 Workstation RC2 even without testing updates, and no accountsservice alert is reported unlike recently.

Well, isn't it simply that displaying of notifications for AVCs broke some time between Beta and now, so when you're running the Beta Shell code, you'll get notifications, but if you install from a current image, you don't?

So today, I 

$ wget https://kojipkgs.fedoraproject.org//work/tasks/8107/14488107/Fedora-Workstation-Live-x86_64-24-1.2.iso

then dd'd it and did an install.  I did get an accountsservice SELinux denial (in my audit log, not as a notification).  I checked the accountsservice version and it was accountsservice-0.6.40-3.fc24 (which doesn't have the fix).

I then did 

# yum update accountsservice --enablerepo=updates-testing

and blew away my audit log, then rebooted.  No more selinux denials.  I think this will be fixed as soon as the update gets pushed from testing.

The difference in experience is simply down to whether display of notifications for AVCs is working or broken when you trigger the AVC, I think. Note that you installed RC-1.2, Jared and dzspam installed Beta.

Dear Joachim
In answer to your assumptions, and in the spirit of contributing to a solution kindly find the below clarifications.
.
1_ Correct - I did not relabel the file system after applying updates/ not sure what that means, but I did not take any action after the update and before the error notifications appeared
.
2_ There were no visible SELinux error notifications prior to the update and the error notifications I reported happened immediately after dnf uppgrade
.
3_ Correct I reported the errors prior to rebooting i.e. immediately after they occurred
.
4_ Not quite sure. I had installed Fedora from the latest Live ISO  on June 14th available through the official website a few hours prior to the update at the following link https://getfedora.org/en/workstation/prerelease/
=> not sure if the fedora website offered a completely outdated beta image or a release canditate material two days ago.
.
Thank you.

(In reply to Ray Strode [halfline] from comment #30)
This alert occurs once and only once after installing a system from Fedora-Workstation-Live-x86_64-24-1.2.iso without any further action taken. This can be verified by checking /var/log/audit/audit.log upon repeated reboots.
No updates, no relabeling of the file system are actually required in this case.

(In reply to Joachim Frieben from comment #33)
> (In reply to Ray Strode [halfline] from comment #30)
> This alert occurs once and only once after installing a system from
> Fedora-Workstation-Live-x86_64-24-1.2.iso without any further action taken.
> This can be verified by checking /var/log/audit/audit.log upon repeated
> reboots.
> No updates, no relabeling of the file system are actually required in this
> case.

That's strange.  The AVC should happen every boot until /root/.cache is created (and it won't get created if selinux is blocking it).  Granted I didn't verify the problem happens every boot. 

Could it be you logged in as root once, thus making /root/.cache get created?

Anyway, I'm almost 100% sure this problem is fixed.

Looks like the update hasn't gone out because this was never accepted as a freeze exception....

well, no-one ever proposed it. it was only proposed as a blocker, and we didn't really think about FEing it when it was reviewed. it doesn't seem that important, as there's no visible notification anyhow.

(In reply to Ray Strode [halfline] from comment #34)
As of accountsservice-0.6.40-3.fc24, the AVC is triggered during system start-up whenever accounts-daemon finds that /root/.cache/ does not exist and creates it. That is why this AVC is triggered every time you boot from the live media and exactly once after you boot into a freshly installed system. There is no need to log in as root. Since the denial is triggered before some user starts a desktop session, there is no notification in the GNOME Shell but the alert is reported in the "SELinux Troubleshooter" utility. The AVC can be triggered by deleting /root/.cache/ and rebooting the system.

i don't understand how it's creating the directory if selinux is blocking it, but maybe the policy is half allowing the mkdir operation or something. i don't know, but it really doesn't matter. 

To be honest, this bug is really minor and was fixed weeks ago.  I think it's gotten far more discussion and far more of all of our time than it should have.  Let's just wait it out from here until the update goes through.

(dropping off cc, if anyone needs me, just ping me)

accountsservice-0.6.40-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.