Bug 1694611

For reference:

> $ id
> uid=210(ossman) gid=20210(ossman) groups=20210(ossman),10(wheel),100(users),495(pkg-build),599(wireshark),4015(tldevel) context=unconfined_u:unconfined_r:unconfined_t:s0

Note that I am a member of wheel. I also have a very low uid (by modern standards), which might be a reason for this bug.

Hello,

thanks for reporting the issue.

First, I'd like to ask what are exact operations you were trying to perform in Control Center and with PackageKit.
Second, I noticed you can set the user to be Standard or Administrator in Users section of Control Center (after unlocking of course).

I failed to reproduce the issue on fresh F29. I created new user with UID=210 and noticed no deviations from normal behaviour of Gnome shell since then.

I must ask what "modern standards" are you referring to. Fedora uses UIDs>1000 by default, since many services, daemons and newly-installed programs use UID<1000 during installation.

https://en.wikipedia.org/wiki/User_identifier#Reserved_ranges

Also:
https://systemd.io/UIDS-GIDS

Possible workaround: create new user with UID>=1000 as intended in Fedora and copy all files from your old /home directory to the new one.

Thanks and have a nice day.

(In reply to Jan Rybar from comment #2)
> First, I'd like to ask what are exact operations you were trying to perform
> in Control Center and with PackageKit.

I've mostly been annoyed with "pkcon install-local" not working. I think this corresponds to the "org.freedesktop.packagekit.package-install-untrusted" action.

> Second, I noticed you can set the user to be Standard or Administrator in
> Users section of Control Center (after unlocking of course).
> 

I don't see my user there unfortunately. Probably has to do with the UID as GNOME rarely shows any users under 1000.

> I failed to reproduce the issue on fresh F29. I created new user with
> UID=210 and noticed no deviations from normal behaviour of Gnome shell since
> then.

Odd. Any suggestions on how to debug the logic picking the user in that case?

> I must ask what "modern standards" are you referring to. Fedora uses
> UIDs>1000 by default, since many services, daemons and newly-installed
> programs use UID<1000 during installation.
> 
> https://en.wikipedia.org/wiki/User_identifier#Reserved_ranges
> 
> Also:
> https://systemd.io/UIDS-GIDS
> 

Your systemd link there even mentions that the limit used to be 100, then 500. :)

This user database has been around since those days. ;)

> Possible workaround: create new user with UID>=1000 as intended in Fedora
> and copy all files from your old /home directory to the new one.
> 

Not really realistic unfortunately. This is a company wide LDAP user account, so there's a bunch of systems that would need to be migrated for that.

(In reply to Pierre Ossman from comment #3)
> (In reply to Jan Rybar from comment #2)
> > First, I'd like to ask what are exact operations you were trying to perform
> > in Control Center and with PackageKit.
> 
> I've mostly been annoyed with "pkcon install-local" not working. I think
> this corresponds to the
> "org.freedesktop.packagekit.package-install-untrusted" action.

Can you please send the printout of that rule?
Most probably /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules

Also the list of /usr/share/polkit-1/rules.d/ might come in hand.

> 
> > Second, I noticed you can set the user to be Standard or Administrator in
> > Users section of Control Center (after unlocking of course).
> > 
> 
> I don't see my user there unfortunately. Probably has to do with the UID as
> GNOME rarely shows any users under 1000.
> 
> > I failed to reproduce the issue on fresh F29. I created new user with
> > UID=210 and noticed no deviations from normal behaviour of Gnome shell since
> > then.
> 
> Odd. Any suggestions on how to debug the logic picking the user in that case?

Maybe output from 'journalctl -u polkit' might help with debugging.
Instead of writing out all ways to enable debuglog in polkit, try this:
https://wiki.kubuntu.org/DebuggingPolicykit

> 
> > I must ask what "modern standards" are you referring to. Fedora uses
> > UIDs>1000 by default, since many services, daemons and newly-installed
> > programs use UID<1000 during installation.
> > 
> > https://en.wikipedia.org/wiki/User_identifier#Reserved_ranges
> > 
> > Also:
> > https://systemd.io/UIDS-GIDS
> > 
> 
> Your systemd link there even mentions that the limit used to be 100, then
> 500. :)

The main reason I mentioned the official page systemd page is this quote:
"Distributions generally split the available UID range in two:

    1…999 → System users. These are users that do not map to actual “human” users, but are used as security identities for system daemons, to implement privilege separation and run system daemons with minimal privileges."

These mentioned ranges can be set during compilation of systemd. Range 0-500 of reserved UIDs is relevant NOW.

> 
> This user database has been around since those days. ;)
> 
> > Possible workaround: create new user with UID>=1000 as intended in Fedora
> > and copy all files from your old /home directory to the new one.
> > 
> 
> Not really realistic unfortunately. This is a company wide LDAP user
> account, so there's a bunch of systems that would need to be migrated for
> that.

This is all that gets printed in the journal when running pkcon and having the authentication dialog show up:

> Apr 01 16:01:32 ossman.lkpg.cendio.se polkitd[1120]: Registered Authentication Agent for unix-process:17734:61347083 (system bus name :1.10113 [/usr/bin/pkttyagent --notify-fd 10 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)

(More messages follow if I dismiss the dialog though)

The rules file looks like this:

> polkit.addRule(function(action, subject) {
>     if (action.id == "org.freedesktop.packagekit.package-install" &&
>         subject.active == true && subject.local == true &&
>         subject.isInGroup("wheel")) {
>             return polkit.Result.YES;
>     }
> });

However, if I understand things correctly this rule only makes sure that is _no_ prompt for a local, active user in "wheel" that is installing a _signed_ package. Right?

The policy for the untrusted install says:

>   <action id="org.freedesktop.packagekit.package-install-untrusted">
>     <icon_name>package-x-generic</icon_name>
>     <defaults>
>       <allow_any>auth_admin</allow_any>
>       <allow_inactive>auth_admin</allow_inactive>
>       <allow_active>auth_admin</allow_active>
>     </defaults>
>     <annotate key="org.freedesktop.policykit.imply">org.freedesktop.packagekit.package-install</annotate>
>   </action>

As for the directory:

> $ sudo ls /usr/share/polkit-1/rules.d/ -1
> 11-fedora-kde-policy.rules
> 20-gnome-initial-setup.rules
> 50-libvirt.rules
> gnome-control-center.rules
> lightdm.rules
> org.freedesktop.bolt.rules
> org.freedesktop.Flatpak.rules
> org.freedesktop.fwupd.rules
> org.freedesktop.packagekit.rules
> org.gtk.vfs.file-operations.rules
> org.projectatomic.rpmostree1.rules
> systemd-networkd.rules

Debugging did not work, unfortunately. The daemon stops working if I add "Environment=G_MESSAGES_DEBUG=all" to the service file. It still starts, but it just rejects everything without any prompt to the user.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Turns out that this is caused by bug 1214026. Closing as duplicate of that.

*** This bug has been marked as a duplicate of bug 1214026 ***