Silverblue authentication request for admin user shown in other users session

Ask Fedora Ask in English
, ,
1

Good day,

on my silverblue installation i have two accounts:

  • “admin” which has admin rights (sudo)
  • “kodi” which does not have admin rights, but is logged in automatically

The problem is that every time kodi logs in gnome shell displays the authentication dialogue for check available updates", but i cannot find which process is requesting the dialogue.

I already checked Gnome Software with both users and auto updates are disabled. I also checked rpm-ostreed.conf and the setting “AutomaticUpdatePolicy” is set to none.

Where else can i look? And where do i see which program requests the authentication dialogue? There was nothing in the journal (searched for PAM).

2 Likes
2

@lightonflux I think you may be hitting this bug:

4 Likes
3

I think this is the case. I will report back if this also happens after the update to 33. But i would be surprised if the issue disappears because of that.

4

Silverblue 33 is affected as well.

5

I am also affected by this using Fedora Silverblue 33. Family members are a bit annoyed by this :frowning:

I tried looking for workarounds. The two things I found didn’t work.

One is

$ cat /etc/rpm-ostreed.conf 
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# For option meanings, see rpm-ostreed.conf(5).

[Daemon]
#AutomaticUpdatePolicy=none
#IdleExitTimeout=60

but as you see AutomaticUpdatePolicy is set to none, which means don’t update, by default.

The second is unchecking Automatic Updates and notifications from Gnome Software’s update preferences. However this doesn’t appear to be respected. Gnome Software still looks for updates without being asked. Incidentally this is annoying because it interferes with my manual commands to check for updates, only one refresh-md can run at a time. I also checked with dconf-editor and download-updates is set to false but the bug is still here.

Anyone can think of any other workaround till the bug is addressed?

1 Like
6

Has anyone found a workaround? I am also affected by this.

1 Like
7

A workaround is adding the user to the admin group. I did it. Not great, but if your threat model is very low it should be fine-ish.

8

And the issue is being worked on. So it just needs to get into a polkit release, which in turn has to be included in Fedora. So i hope this will be fixed with 35 at the latest.

1 Like