polkitd hardwired to user=tc?

[GNUser]

I'm on TCL16 x86_64, tinkering with dbus and polkit to try to understand how it all works.

I use  user=bruno  bootcode and would like  polkitd  to use my home directory, but it insists on using  /home/tc  even though I've changed the user in polkit's config file (/usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf) to "bruno":

Code: [Select]

$ cat /proc/cmdline
...user=bruno...

$ whoami
bruno

$ grep user /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf
  <policy user="bruno">
  <policy user="bruno">

$ sudo /usr/local/lib/polkit-1/polkitd &
Error switching to user tc: Error changing to home directory /home/tc: No such file or directory
Exiting with code 1
Please, how do I force polkitd to use user "bruno" rather than user "tc"?

[Rich]

Hi GNUser
Maybe check:

Code: [Select]

/usr/local/share/dbus-1/system.conf

[GNUser]

Hi Rich. No luck--even if all references to user  tc  in  /usr/local/share/dbus-1/system.conf  and  /usr/local/etc/dbus-1/system.d/org.freedesktop.PolicyKit1.conf  are changed to  bruno, polkit still insists on user tc:

Code: [Select]

$ grep user /usr/local/share/dbus-1/system.conf
     auth mechanisms, run as a different user, etc. -->
  <!-- Run as special user -->
  <user>bruno</user>
    <!-- All users can connect to system bus -->
    <allow user="*"/>
  <policy user="root">
  <policy user="root">
       enable other privileged users to view statistics and debug info -->
  <policy user="root">
  <!-- <limit name="max_connections_per_user">256</limit> -->

$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...

$ ps -ef | grep dbus-daemon
 7667 bruno    dbus-daemon --nofork --print-address 4 --session
24133 bruno    /usr/local/bin/dbus-daemon --system   # note that dbus does honor the user setting in /usr/local/share/dbus-1/system.conf
24200 bruno    grep dbus-daemon

$ sudo /usr/local/lib/polkit-1/polkitd &
Error switching to user tc: Error changing to home directory /home/tc: No such file or directory
Exiting with code 1


[GNUser]

I noticed that in Devuan, polkitd runs as user "polkitd" so maybe the uid doesn't matter very much (i.e., it's all about the rules in /usr/local/share/polkit-1/)?

Code: [Select]

Devuan$ ps -ef | grep polkit
polkitd   1349     1  0 12:40 ?        00:00:00 /usr/lib/polkit-1/polkitd --no-debug
Even if ultimately doesn't matter much, I'm a bit puzzled about polkitd's insistence on running as user tc.

[Rich]

Hi GNUser
I did find this:

Code: [Select]

tc@box:~$ sudo grep -iR tc /usr/local/share/polkit-1/actions/* | grep -i user
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>
/usr/local/share/polkit-1/actions/org.freedesktop.color.policy:    <annotate key="org.freedesktop.policykit.owner">unix-user:tc</annotate>But that file is not part of the extension. It gets created somehow.

And I know we don't support system.d, but it looks like this might be involved:

Code: [Select]

tc@box:~$ sudo grep -iR tc /usr/local/share/dbus-1/system.d/org.freedesktop.ColorManager.conf  | grep -i user
  <!-- Only user root or user tc can own the colord service -->
  <policy user="tc">

[GNUser]

And I know we don't support system.d

Hi Rich. I think  system.d  in this context (/usr/local/share/dbus-1/system.d/) means something like "directory for dbus system bus configuration files" (as opposed to dbus session bus). I don't think it's a reference to the infamous  systemd  init system.

Rant: These linux-specific daemons (dbus, policykit, consolekit) are a royal PITA--every time I take a stab at trying to understand them, I end up regretting it. I'm glad that, even though TCL has these devils in the repo, they are not deeply integrated into the OS

[GNUser]

Hi Rich. I don't have  colord.tcz  loaded, so it cannot be responsible for polkitd's unexpected behavior.

Code: [Select]

$ tce-status -i | grep colord
$

$ find /usr/local/share/polkit-1
/usr/local/share/polkit-1
/usr/local/share/polkit-1/actions
/usr/local/share/polkit-1/actions/org.x.xf86-video-intel.backlight-helper.policy
/usr/local/share/polkit-1/actions/org.freedesktop.login1.policy

$ find /usr/local/share/dbus-1
/usr/local/share/dbus-1
/usr/local/share/dbus-1/system-services
/usr/local/share/dbus-1/system-services/org.freedesktop.login1.service
/usr/local/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service
/usr/local/share/dbus-1/session.conf
/usr/local/share/dbus-1/system.conf
/usr/local/share/dbus-1/accessibility-services
/usr/local/share/dbus-1/accessibility-services/org.a11y.atspi.Registry.service
/usr/local/share/dbus-1/services
/usr/local/share/dbus-1/services/org.a11y.Bus.service

[GNUser]

What I'm actually trying to do is to figure out a way to use  flatpak  without the  --user  flag. It works in Devuan but not in TCL16 x86_64.

Does anyone think the following is worth investigating, or is it more trouble than it's worth? It seems that it's a problem with how flatpak interacts with dbus +/- polkit:

Code: [Select]

bruno@x230:~$ tce-load -wil flatpak

bruno@x230:~$ mkdir /home/tc

bruno@x230:~$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...

bruno@x230:~$ sudo /usr/local/lib/polkit-1/polkitd &
Successfully changed to user tc
Error getting login monitor: -215:02:40.365: Loading rules from directory /usr/local/etc/polkit-1/rules.d
15:02:40.366: Loading rules from directory /usr/local/share/polkit-1/rules.d
15:02:40.366: Finished loading, compiling and executing 2 rules
Entering main event loop
Connected to the system bus
15:02:40.367: Acquired the name org.freedesktop.PolicyKit1 on the system bus

bruno@x230:~$ flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo

Note that the directories

'/var/local/lib/flatpak/exports/share'
'/home/bruno/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

15:02:57.458: Registered Authentication Agent for unix-process:10702:25666 (system bus name :1.1 [flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
15:02:57.488: Unregistered Authentication Agent for unix-process:10702:25666 (system bus name :1.1, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
error: Flatpak system operation EnsureRepo not allowed for user

Code: [Select]

$ cat /usr/local/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules
polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.Flatpak.app-install" ||
         action.id == "org.freedesktop.Flatpak.runtime-install"||
         action.id == "org.freedesktop.Flatpak.app-uninstall" ||
         action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
         action.id == "org.freedesktop.Flatpak.modify-repo") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
            return polkit.Result.AUTH_ADMIN;
    }

    return polkit.Result.NOT_HANDLED;
});

$ id
uid=1000(bruno) gid=50(staff) groups=10(wheel),50(staff),1000(bruno)I'm in the "wheel" group so polkit should let me do flatpak things with the implied  --system  flag, right?

P.S. If I can figure this out, I will resubmit the flatpak extension so that the polkit rule looks for "staff" group rather than "wheel". But for my purposes right now it doesn't make a difference because my system has both groups and I'm part of both.

[GNUser]

I figured it out. The  remote-add  action is privileged--on Devuan a window pops up asking for root password.

On TCL, this works just fine:

Code: [Select]

$ tce-load -i flatpak
$ sudo /usr/local/etc/init.d/dbus start
$ mkdir /home/tc; sudo /usr/local/lib/polkit-1/polkitd &
$ sudo flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak install flathub org.kde.kcalc # the --system flag is implied when --user isn't used
So, at the end of the day, there are only 2 problems here:

1. polkitd won't start for me until /home/tc exists on my system. Maybe polkit's startup script should create a /home/tc directory if one doesn't already exist?

2. flatpak's /usr/local/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules uses membership in "wheel" group to authenticate users. I'm going to change that to "staff" because TCL does not come with a "wheel" group out of the box.

[GNUser]

My conclusion is that flatpak is complex and interacts with dbus, polkit, and XDG* environmental variables in ways that are difficult to understand. I can't really recommend flatpak--I packaged it for the x86_64 repo mostly because I like a good challenge

But if you must use flatpak, I would definitely recommend always using the  --user  flag (it eliminates all chit-chat between flatpak and polkit, thus decreasing complexity) by adding this line to your ~/.ashrc:

Code: [Select]

alias flatpak='flatpak --user'

Happy hacking!