WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Recent Posts

Pages: 1 2 3 [4] 5 6 ... 10
31
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last 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.
32
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last 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
33
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last post by GNUser on December 18, 2025, 01:37:41 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
34
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last 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
  <!-- Only user root or user tc can own the colord service -->
  <policy user="tc">
35
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last 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.
36
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last 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. -->
  <!-- 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
37
TCE Bugs / Re: polkitd hardwired to user=tc?
« Last post by Rich on December 18, 2025, 12:29:21 PM »
Hi GNUser
Maybe check:
Code: [Select]
/usr/local/share/dbus-1/system.conf
38
TCE Bugs / polkitd hardwired to user=tc?
« Last 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"?
39
Micro Core / Re: Core install with 32 MB RAM on 486
« Last post by branpurn on December 18, 2025, 09:50:53 AM »
Missed edit window

Paying more attention to that latest screen cap vs. my first, it looks like kernel extraction is complete? Different error (but still goes away w/ increased RAM)
40
Micro Core / Re: Core install with 32 MB RAM on 486
« Last post by branpurn on December 18, 2025, 08:45:02 AM »
Took another quick stab at this yesterday with both a reduced core.gz and rootfs.gz; I stripped out extra from core.gz in addition to the script, but not enough; kernel panic (tested on both Core and TinyCore)

I verified beforehand that stripped media was still bootable with higher amount of RAM (tested at 64 MB); also noting, between the DRAM card and onboard mem, I have about 36 MB on the 486.
Pages: 1 2 3 [4] 5 6 ... 10