Tiny Core Linux

Tiny Core Extensions => TCE Bugs => Topic started by: GNUser on December 18, 2025, 11:15:08 AM

Title: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 11:15:08 AM: 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"?
Title: Re: polkitd hardwired to user=tc?
Post by: Rich on December 18, 2025, 12:29:21 PM: Hi GNUser
Maybe check:
Code: [Select]
/usr/local/share/dbus-1/system.conf
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 12:40:14 PM: 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. -->  <user>bruno</user>  <allow user="*"/> <policy user="root"> <policy user="root"> enable other privileged users to view statistics and debug info --> <policy user="root">  $ 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
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 12:46:50 PM: 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.
Title: Re: polkitd hardwired to user=tc?
Post by: Rich on December 18, 2025, 01:22:16 PM: 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  <policy user="tc">
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 01:37:41 PM: Quote from: Rich on December 18, 2025, 01:22:16 PM
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 ;D
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 02:43:22 PM: 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
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 03:07:24 PM: 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.
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 18, 2025, 03:40:12 PM: 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.
Title: Re: polkitd hardwired to user=tc?
Post by: GNUser on December 19, 2025, 09:12:34 AM: 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!