Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1870476 - Google Account doesn't work during initial setup
Summary: Google Account doesn't work during initial setup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 33
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
Depends On:
Blocks: F33BetaFreezeException F33FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-08-20 07:50 UTC by Alessio
Modified: 2020-09-21 20:49 UTC (History)
15 users (show)

Fixed In Version: selinux-policy-3.14.6-26.fc33 selinux-policy-3.14.6-27.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-21 20:49:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
ausearch (deleted)
2020-08-26 06:39 UTC, Alessio
no flags Details
journalctl excerpt (deleted)
2020-08-26 06:44 UTC, Alessio
no flags Details
ausearch permissive (deleted)
2020-08-26 07:51 UTC, Alessio
no flags Details
ausearch output (deleted)
2020-09-17 08:46 UTC, Kamil Páral
no flags Details

Description Alessio 2020-08-20 07:50:33 UTC
Description of problem:

During GNOME initial setup, Google Account stays stuck without displaying anything.

Comment 1 Alessio 2020-08-20 07:51:37 UTC
It works if used once logged in to GNOME.

Comment 2 Alessio 2020-08-20 08:33:17 UTC
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.

Comment 3 Debarshi Ray 2020-08-20 12:32:19 UTC
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

Comment 4 Debarshi Ray 2020-08-20 12:34:30 UTC
Also, what's the output of:
  $ rpm -q webkit2gtk3 gnome-online-accounts

Comment 5 Ondřej Míchal 2020-08-20 12:55:05 UTC
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

Comment 6 Michael Catanzaro 2020-08-20 16:13:33 UTC
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....

Comment 7 Michael Catanzaro 2020-08-20 16:24:02 UTC
> $ /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.

Comment 8 Alessio 2020-08-20 16:28:30 UTC
This is a screenshot of what happens.

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

Comment 9 Alessio 2020-08-20 16:57:12 UTC
For the records, the issue is the same also with Facebook.

Comment 10 Alessio 2020-08-20 16:59:21 UTC
Ah!
If I pass selinux=0 to grub, then it works.

Comment 11 Alessio 2020-08-25 08:45:33 UTC
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

Comment 12 Michael Catanzaro 2020-08-25 16:52:52 UTC
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.

Comment 13 Adam Williamson 2020-08-25 16:59:02 UTC
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.

Comment 14 Zdenek Pytela 2020-08-25 17:24:02 UTC
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.

Comment 15 Michael Catanzaro 2020-08-25 19:55:44 UTC
(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

Comment 16 Adam Williamson 2020-08-25 20:26:52 UTC
"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'...

Comment 17 Adam Williamson 2020-08-25 20:41:46 UTC
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.

Comment 18 Michael Catanzaro 2020-08-25 20:45:12 UTC
(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....

Comment 19 Michael Catanzaro 2020-08-25 20:47:57 UTC
(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!

Comment 20 Alessio 2020-08-26 06:39:43 UTC
Created attachment 1712629 [details]
ausearch

Comment 21 Alessio 2020-08-26 06:42:56 UTC
I followed the instructions by modifing the audit.rules file just after the installation (from Live) ended.
See the attached files.

Comment 22 Alessio 2020-08-26 06:44:27 UTC
Created attachment 1712630 [details]
journalctl excerpt

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

Comment 23 Zdenek Pytela 2020-08-26 07:17:26 UTC
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.)

Comment 24 Alessio 2020-08-26 07:51:18 UTC
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

Comment 25 Alessio 2020-08-26 07:52:35 UTC
(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

Comment 26 Kamil Páral 2020-08-26 10:34:44 UTC
(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.

Comment 27 Michael Catanzaro 2020-08-26 13:05:11 UTC
Nice, thanks Alessio!

Comment 28 Adam Williamson 2020-08-28 17:36:50 UTC
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.

Comment 29 Zdenek Pytela 2020-09-04 16:15:21 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/429

Comment 30 Michael Catanzaro 2020-09-04 17:23:47 UTC
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.

Comment 31 Zdenek Pytela 2020-09-07 13:16:11 UTC
It will be a part of the next selinux-policy build both for f33 and f34 in a few days.

Comment 32 Michael Catanzaro 2020-09-07 15:09:28 UTC
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.

Comment 33 Adam Williamson 2020-09-08 19:26:13 UTC
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

Comment 34 Zdenek Pytela 2020-09-09 14:03:10 UTC
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.

Comment 35 Michael Catanzaro 2020-09-09 20:35:15 UTC
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....

Comment 36 Adam Williamson 2020-09-09 20:47:33 UTC
right, if you can do a build+update soon it'd be great, Zdenek.

Comment 37 Fedora Update System 2020-09-11 09:13:38 UTC
FEDORA-2020-9f6842e43f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9f6842e43f

Comment 38 Fedora Update System 2020-09-11 20:18:16 UTC
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.

Comment 39 Fedora Update System 2020-09-14 23:44:31 UTC
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.

Comment 40 Kamil Páral 2020-09-15 08:24:58 UTC
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.

Comment 41 Zdenek Pytela 2020-09-15 08:33:08 UTC
Kamil,

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

Comment 42 Kamil Páral 2020-09-15 14:32:44 UTC
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.

Comment 43 Zdenek Pytela 2020-09-16 20:38:47 UTC
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.

Comment 44 Kamil Páral 2020-09-17 08:46:56 UTC
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.

Comment 45 Zdenek Pytela 2020-09-17 09:11:49 UTC
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.

Comment 46 Kamil Páral 2020-09-17 11:09:06 UTC
(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?

Comment 47 Zdenek Pytela 2020-09-17 12:41:52 UTC
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.

Comment 48 Fedora Update System 2020-09-18 13:52:42 UTC
FEDORA-2020-2be8afa1ab has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2be8afa1ab

Comment 49 Kamil Páral 2020-09-18 15:00:49 UTC
(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.

Comment 50 Fedora Update System 2020-09-18 19:00:51 UTC
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.

Comment 51 Adam Williamson 2020-09-21 19:36:57 UTC
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."

Comment 52 Fedora Update System 2020-09-21 20:49:23 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.