It works if used once logged in to GNOME.

And it happens only after the installation. The first user initial setup.
If I create a new user, and initial setup start for this one, it works.

Ok, this is very interesting. Are you saying that the embedded web view/browser wasn't showing anything?

Is there any chance that you have the LD_LIBRARY_PATH environment variable set? Do you have the following line in your systemd journal:
  bwrap: Can't create file at /.flatpak-info: Read-only file system

Also, what's the output of:
  $ rpm -q webkit2gtk3 gnome-online-accounts

I also experienced this issue when installing Fedora Silverblue Rawhide (Rawhide.20200811.n.0). The initial setup started but after clicking on the Google button (or any other that does not spawn a native dialog window) the spawned window stayed blank (possibly just a loading bar at the top the first the window was opened). After skipping this section and finishing the initial setup, I added the Google account from gnome-settings without any problems.

I went from the systemd journal and did not find the line Debarshi mentioned.

$ rpm -q webkit2gtk3 gnome-online-accounts
webkit2gtk3-2.29.4-1.fc33.x86_64
gnome-online-accounts-3.37.90-1.fc33.x86_64

Um weird. Normally this would be a graphics problem or maybe a sandboxing problem, but the fact that it works in new user mode (on first boot, where it has to create the first user account) and only fails in existing user mode (when running for newly-created user accounts) suggests otherwise. Can you reproduce if you run:

$ /usr/libexec/gnome-initial-setup --existing-user

from your regular user session? And, if so, do any error messages appear in the terminal?

If not, any relevant error messages of any sort in your journal? This is the sort of bug that likely won't be solved if there's no error messages....

> $ /usr/libexec/gnome-initial-setup --existing-user

OK I actually misread your complaints. It sounds like the bug only occurs on the very first boot. So /usr/libexec/gnome-initial-setup --existing-user would be expected to work and there's no point in checking that.

So if the bug probably only occurs when running in the gnome-initial-setup user session... well, that is not an easy environment in which to replicate anything. I wonder if we have some hack to allow starting that session without deleting all active users. Then we'd need a way to get a terminal inside the session. That all will probably require changes in gdm to facilitate....

If you happen to see anything incriminating in your journal, that would be wonderful and much simpler than trying to engineer some way to debug this. Probably something going wrong with the sandbox, I'd expect.

This is a screenshot of what happens.

https://alciregi.fedorapeople.org/screenshot/ggl.png

For the records, the issue is the same also with Facebook.

Ah!
If I pass selinux=0 to grub, then it works.

These are the avc denials just after the first user creation (where I was trying to unsuccessfully create an online account during the initial setup).

type=AVC msg=audit(1598344550.424:257): avc:  denied  { getattr } for  pid=1435 comm="bwrap" path="uts:[4026532350]" dev="nsfs" ino=4026532350 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:nsfs_t:s0 tclass=file permissive=0

type=AVC msg=audit(1598344550.424:258): avc:  denied  { net_admin } for  pid=1436 comm="bwrap" capability=12  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=cap_userns permissive=0

Looks like gnome-initial-setup is running with system_u:system_r:xdm_t context (should it be?). selinux doesn't let it use getattr or user namespace, but both are required by bubblewrap. If bubblewrap doesn't work, we get no web view. Wasn't a problem before F33 because the online accounts page was previously unsandboxed.

proposing as a Beta freeze exception issue. This doesn't really hit any of the blocker criteria I can think of, but it certainly would be good to fix it for Beta.

I will try to reproduce it to gather all denials as getattr is probably not enough.

I'd be grateful though if somebody really using these services would help with that, it means set system to permissive mode and enable full auditing:

0) Run
   # setenforce 0
1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run the scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Additionally, I am not confident why net_admin capability would be necessary:

       CAP_NET_ADMIN
              Perform various network-related operations:
              * interface configuration;
              * administration of IP firewall, masquerading, and accounting;
              * modify routing tables;
              * bind to any address for transparent proxying;
              * set type-of-service (TOS)
              * clear driver statistics;
              * set promiscuous mode;
              * enabling multicasting;
              * use setsockopt(2) to set the  following  socket  options:  SO_DEBUG,  SO_MARK,
                SO_PRIORITY  (for  a  priority  outside the range 0 to 6), SO_RCVBUFFORCE, and
                SO_SNDBUFFORCE.

Rishi, Michael, do you happen to know the answer? It seems to have been requested in the namespaces context, too.

(In reply to Zdenek Pytela from comment #14)
> I will try to reproduce it to gather all denials as getattr is probably not
> enough.
> 
> I'd be grateful though if somebody really using these services would help
> with that, it means set system to permissive mode and enable full auditing:
> 
> 0) Run
>    # setenforce 0
> 1) Open the /etc/audit/rules.d/audit.rules file in an editor.
> 2) Remove the following line if it exists:
> -a task,never
> 3) Add the following line to the end of the file:
> -w /etc/shadow -p w
> 4) Restart the audit daemon:
>   # service auditd restart
> 5) Re-run the scenario.
> 6) Collect AVC denials:
>   # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Thanks for the quick reply. Hm, the problem is we can't actually do any of this until after we've finished initial setup, at which point it's too late to reproduce the bug. This would be a lot easier if we had a way to reproduce this bug outside the initial setup session without having to build a modified gdm. So for testing purposes, maybe we can do that by changing the selinux context on the gnome-initial-setup binary? I built a custom version of gnome-initial-setup with jhbuild and attempted to set:

$ sudo chcon -u system_u -r system_r -t xdm_t gnome-initial-setup
chcon: failed to change context of 'gnome-initial-setup' to ‘system_u:system_r:xdm_t:s0’: Permission denied

which probably just reveals that I don't know how selinux is supposed to work, but I'm surprised to see permission denied when using sudo.

Next I tried unlocking the gnome-initial-setup user with passwd, manually changing its shell to /bin/bash to try to log in. I was able to do that successfully, but wasn't able to start gnome-initial-setup:

bash-5.0$ ./gnome-initial-setup
No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: Could not connect: Connection refused

(gnome-initial-setup:1064180): Gtk-WARNING **: 14:49:28.865: cannot open display: :0

I verified that $WAYLAND_DISPLAY was set to wayland-0, but it's no surprise this doesn't work since the compositor is running as a different user. Next I tried logging into the unlocked gnome-initial-setup user from gdm using the 'Not Listed?' functionality. This actually worked, but keyboard layout was forced to English (US) and neither gnome-initial-setup itself nor gnome-control-center was able to change that: attempts to change keyboard layout just failed. I wound up giving up since I couldn't practically type anything.

I'm open to other creative suggestions as to how we could try debugging this.

> Additionally, I am not confident why net_admin capability would be necessary:

Hm, I found a comment in bubblewrap.c [1][2] indicating it might be for fuse? It does seem weird, but it should only be needed in the user namespace. I don't think it should be needed in the host. Honestly I'm not sure how this works. :) We can ask bubblewrap devs to comment if needed.

[1] https://github.com/containers/bubblewrap/blob/4c35d7a5f92499d6ed646d4a5ffad9acc10cb432/bubblewrap.c#L582
[2] https://github.com/containers/bubblewrap/blob/4c35d7a5f92499d6ed646d4a5ffad9acc10cb432/bubblewrap.c#L808

"Hm, the problem is we can't actually do any of this until after we've finished initial setup"

Couldn't you just boot the first time post-install at runlevel 3, then log into a console and do all the modifications? then reboot normally and "first boot" g-i-s mode should come up. Or just do 'systemctl isolate graphical.target'...

oh, I guess for Workstation we don't allow user creation during install, do we? Well, alternatively, chroot into the installed system at the end of install and make the changes there before rebooting. It's left mounted at `/mnt/sysimage` as long as you leave the installer running.

(In reply to Adam Williamson from comment #17)
> oh, I guess for Workstation we don't allow user creation during install, do
> we? Well, alternatively, chroot into the installed system at the end of
> install and make the changes there before rebooting. It's left mounted at
> `/mnt/sysimage` as long as you leave the installer running.

OK, I'll try to chroot and see how it goes....

(In reply to Alessio from comment #0)
> Description of problem:
> 
> During GNOME initial setup, Google Account stays stuck without displaying
> anything.

BTW, thanks for discovering this nice and early, even before beta release. Good testing!

Created attachment 1712629 [details]
ausearch

I followed the instructions by modifing the audit.rules file just after the installation (from Live) ended.
See the attached files.

Created attachment 1712630 [details]
journalctl excerpt

This is an extract of journalctl just after selecting Google online account

Alessio,

Thanks for the files with the additional information. However, the permissive=0 indicates SELinux is in enforcing mode. Will it be possible to gather the permissions in permissive? Either one-time with setenforce 0 or permanently in /etc/selinux/config. Another, rather painful way, would be insert the permissions as they are found, i. e.

  # cat local_gis1.cil
(allow local_login_t proc_t (filesystem (getattr)))
(allow xdm_t nsfs_t (file (getattr)))
(allow xdm_t self (cap_userns (net_admin)))

  # semodule -i local_gis1.cil

and repeat again. (The first one is not related, it already is fixed in the current policy.)

Created attachment 1712641 [details]
ausearch permissive

[root@localhost ~]# getenforce 
Permissive

[root@localhost ~]# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today^C

(In reply to Zdenek Pytela from comment #23)
> Alessio,
> 
> Thanks for the files with the additional information. However, the
> permissive=0 indicates SELinux is in enforcing mode. 

Whoops.
I repeated the process with SELINUX=permissive in /etc/selinux/config

(In reply to Adam Williamson from comment #17)
> oh, I guess for Workstation we don't allow user creation during install, do
> we? Well, alternatively, chroot into the installed system at the end of
> install and make the changes there before rebooting. It's left mounted at
> `/mnt/sysimage` as long as you leave the installer running.

Another way is to use the netinst image which allows you to create the root user during the install process.

Nice, thanks Alessio!

We have -4 Blocker / +4 FE votes in the ticket:
https://pagure.io/fedora-qa/blocker-review/issue/38

so setting accepted FE, rejected blocker.

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/429

Thanks a bunch!

Since we have a FE for this, can you also do a F33 update please? Then we can verify that it's indeed working properly in F33 beta.

It will be a part of the next selinux-policy build both for f33 and f34 in a few days.

Problem is we don't want to accept an entire new selinux-policy build as a freeze exception, since selinux-policy updates are frankly a bit dangerous and we don't want to potentially introduce new blockers right before beta release. I should have been more specific: it would be good to have a new build with *only* this fix. Then once it goes stable, then we can do the regular selinux-policy update as usual.

Well, the selinux policy team does have a rule that after a certain point in the cycle (though I'm not actually sure what point that is right now) they don't make changes that make things more strict, only more permissive. So selinux-policy updates are usually pretty safe. Except on a couple of occasions when there have been typos. :P

Adam,

You are right. Now we are at the moment when f33 splits off rawhide and we will be now delivering to f33 only bugfixes adding new permissions, not new features or significant changes.

Anyway the beta release has slipped a week, so we have a couple more days. It would still be good to have an update prepared ASAP so we can get this into beta. If it's broken in beta, the chances that nobody will test it and it will be broken again in final increase dramatically....

right, if you can do a build+update soon it'd be great, Zdenek.

FEDORA-2020-9f6842e43f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f6842e43f

FEDORA-2020-9f6842e43f has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9f6842e43f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f6842e43f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-9f6842e43f has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

I installed F33 Workstation from netinst, created root account in the installer, then rebooted into the system, updated to selinux-policy-3.14.6-26.fc33, rebooted, and tested the gnome-initial-setup. I still can't display any web form to add Google or other account. This still seems broken. We might try again once there is a new compose with the new selinux-policy baked in.

Kamil,

Will you be able to follow the steps to gather AVC denials (c#14 and further hints)?

Now that we have a new criterion specifically for this:
https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#First_boot_experience
nominating as a FinalBlocker.

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/432

No I am still unable to reproduce the issue as reported. A build will be available soon.

Created attachment 1715190 [details]
ausearch output

(In reply to Zdenek Pytela from comment #41)
> Will you be able to follow the steps to gather AVC denials (c#14 and further
> hints)?

I was, but step #4 didn't work as expected:

> $ systemctl restart auditd.service
> Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop).
> See system logs and 'systemctl status auditd.service' for details.

So I had to reboot instead.

See the attached ausearch output.

Kamile,

Thank you, I've updated the PR.

Note the instruction actually work as expected when followed literally - using the service command in place of systemctl is not just old-school and is not a mistake.

(In reply to Zdenek Pytela from comment #45)
> Note the instruction actually work as expected when followed literally -
> using the service command in place of systemctl is not just old-school and
> is not a mistake.

Hah, today I learned! :o) I'd love to understand why it works differently, though. Do you know?

I am not sure if we can call it a dirty trick or if it is the only supported way of restarting auditd, but I am for recommending it as long as the service command is present in distribution.

So the service command is now the only proper means for controlling auditd as a service. For the auid value be properly recorded, systemctl command cannot be used to restrat the service.

FEDORA-2020-2be8afa1ab has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2be8afa1ab

(In reply to Fedora Update System from comment #48)
> FEDORA-2020-2be8afa1ab has been submitted as an update to Fedora 33.
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-2be8afa1ab

This update fixes the problem for me. I added a Google online account inside the gnome-initial-setup and it was properly connected afterwards.

FEDORA-2020-2be8afa1ab has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2be8afa1ab`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2be8afa1ab

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Discussed at 2020-09-21 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-09-21/f33-blocker-review.2020-09-21-16.00.html . Accepted as a Final blocker as a violation of the newly adapted criterion "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test."

FEDORA-2020-2be8afa1ab has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.