Re: [systemd-devel] timedate1 permissions

[Greg Wilson-Lindberg]

Hi Mantas,
That was the advice that I needed.
I modified our Yocto build to include polkit, added datetime group to our user 
and now it’s working.

Thanks,
Greg

From: Mantas Mikulėnas 
Sent: Wednesday, February 17, 2021 10:56 AM
To: Greg Wilson-Lindberg 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] timedate1 permissions

Systemd D-Bus services use polkit for authorization when the message is sent by 
someone not uid 0. Depending on which version you have, you can write a .pkla 
file (Debian) or a JavaScript function (other distros) that allows a specific 
action for a specific user or group.

You'll want to allow the "org.freedesktop.timedate1.set-timezone" action (see 
`pkaction`). Recent versions have some documentation in `man 8 polkit`.

If the system doesn't have polkit installed, then all you have is the hardcoded 
"uid == 0" check. (Polkit *is* the configuration facility for that.)


On Wed, Feb 17, 2021 at 8:18 PM Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:
First, I hope that I have found the proper list for this question, if not I'm 
sorry to bother you all.

I'm trying to run a program that changes the timezone. Our application is using 
the dbus facility to change the time zone. It works when run as root but fails 
when run as our user. I had thought initially that the problem was with dbus 
permissions but have since found out that the fact that the messages are going 
over the dbus means that the dbus permissions are set correctly.

So, it seems that the systemd.timedate1 utility has it's own permissions that 
is rejecting our request to change the timezone. My question at this point 
becomes, how do I change the permissions for the system.timedate1 utility to 
allow my non-root user to change the time and timezone?

Regards,
Greg Wilson-Lindberg
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-ask-password causes systemd to use very high CPU

[Barry Scott]

Is there any work around that I can use?

Barry


> On 23 Jan 2021, at 14:32, Barry Scott  wrote:
> 
> I opened this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1919538 
> 
> 
> I'd love to know if there is a work around until you have time to make a fix.
> 
> Barry
> 
> 
> 
>> On 16 Jan 2021, at 15:42, Barry Scott > > wrote:
>> 
>> I have a reproducible problem with systemd-ask-password.
>> 
>> # rpm -q systemd
>> systemd-246.7-2.fc33.x86_64
>> 
>> 1. boot fedora 33
>> 2. login to KDE
>> 3. start a terminal and run top
>> 4. start a terminal and run:
>>   systemctl >before
>>   systemd-ask-password 'testing: ' p
>> 5. Observe that top is showing systemd using ~80% CPU
>> 6. stop systemd-ask-password and CPU returns to idle
>>   systemctl >after
>> 7. Check journal:
>> 
>> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted 
>> in Forward Password Requests to Plymouth being skipped.
>> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted 
>> in Forward Password Requests to Plymouth being skipped.
>> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted 
>> in Forward Password Requests to Plymouth being skipped.
>> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted 
>> in Forward Password Requests to Plymouth being skipped.
>> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted 
>> in Forward Password Requests to Plymouth being skipped.
>> Jan 16 15:18:19 vmf33.chelsea.private systemd[1]: Condition check resulted 
>> in Forward Password Requests to Plymouth being skipped.
>> etc...
>> 
>> # journalctl -b  | grep Condition | wc -l
>> 37555
>> 
>> 8. run again:
>>   systemd-ask-password 'testing: ' p
>> 9. messgae sent to all terminals:
>> Broadcast message from root@vmf33.chelsea.private 
>>  (Sat 2021-01-16 15:28:02 GMT):
>> 
>> Password entry required for 'testing:' (PID 1862).
>> Please enter password with the systemd-tty-ask-password-agent tool.
>> 
>> -
>> 
>> Looking at the services before and after running systemd-ask-password once I 
>> see this diff:
>> 
>> # diff -u before after | grep '^[-+]'
>> --- before  2021-01-16 15:35:51.850438282 +
>> +++ after   2021-01-16 15:36:08.875736785 +
>> -  systemd-ask-password-plymouth.path
>>loaded active waiting   Forward Password 
>> Requests to Plymouth Directory Watch 
>>
>> -  systemd-ask-password-wall.path
>>loaded active waiting   Forward Password 
>> Requests to Wall Directory Watch 
>>
>> +  systemd-ask-password-wall.path
>>loaded active running   Forward Password 
>> Requests to Wall Directory Watch 
>>
>> -  fprintd.service   
>>loaded active running   Fingerprint 
>> Authentication Daemon
>> 
>> +  systemd-ask-password-wall.service 
>>loaded active running   Forward Password 
>> Requests to Wall 
>>
>> -196 loaded units listed. Pass --all to see loaded but inactive units, too.
>> +195 loaded units listed. Pass --all to see loaded but inactive units, too.
>> 
>> I am seeing this behaviour on two systems. A dell laptop and a VMware VM.
>> 
>> Is there anything I can do to help debug this?
>> Or just raise a big report?
>> 
>> What work around would you suggest I use until this is fixed?
>> 
>> Barry
>> 
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org 
>> 
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timedate1 permissions

[Mantas Mikulėnas]

Systemd D-Bus services use polkit for authorization when the message is
sent by someone not uid 0. Depending on which version you have, you can
write a .pkla file (Debian) or a JavaScript function (other distros) that
allows a specific action for a specific user or group.

You'll want to allow the "org.freedesktop.timedate1.set-timezone" action
(see `pkaction`). Recent versions have some documentation in `man 8 polkit`.

If the system doesn't have polkit installed, then all you have is the
hardcoded "uid == 0" check. (Polkit *is* the configuration facility for
that.)


On Wed, Feb 17, 2021 at 8:18 PM Greg Wilson-Lindberg 
wrote:

> First, I hope that I have found the proper list for this question, if not
> I'm sorry to bother you all.
>
> I'm trying to run a program that changes the timezone. Our application is
> using the dbus facility to change the time zone. It works when run as root
> but fails when run as our user. I had thought initially that the problem
> was with dbus permissions but have since found out that the fact that the
> messages are going over the dbus means that the dbus permissions are set
> correctly.
>
> So, it seems that the systemd.timedate1 utility has it's own permissions
> that is rejecting our request to change the timezone. My question at this
> point becomes, how do I change the permissions for the system.timedate1
> utility to allow my non-root user to change the time and timezone?
>
> Regards,
> Greg Wilson-Lindberg
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] timedate1 permissions

[Greg Wilson-Lindberg]

First, I hope that I have found the proper list for this question, if not I'm 
sorry to bother you all.

I'm trying to run a program that changes the timezone. Our application is using 
the dbus facility to change the time zone. It works when run as root but fails 
when run as our user. I had thought initially that the problem was with dbus 
permissions but have since found out that the fact that the messages are going 
over the dbus means that the dbus permissions are set correctly.

So, it seems that the systemd.timedate1 utility has it's own permissions that 
is rejecting our request to change the timezone. My question at this point 
becomes, how do I change the permissions for the system.timedate1 utility to 
allow my non-root user to change the time and timezone?

Regards,
Greg Wilson-Lindberg
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Design patterns for privilege separating systemd services?

[Colin Walters]

I'm having a debate with the SSSD team over here around multiple systemd units 
and privilege separation: https://github.com/SSSD/sssd/issues/3412

And we also had a related topic come up in Fedora CoreOS where we have a 
privileged service (rpm-ostreed.service) and we want a separate unprivileged 
management service (zincati.service) to be able to perform privileged 
operations; right now we install a polkit rule to authorize the `zincati` user, 
but I think that's quite hacky.  I'd actually like to use DynamicUser=yes for 
zincati.

I think what I want is a way to tell systemd to create something like a private 
socketpair() between the two services dynamically.  So the "privileged" part of 
zincati.service is just a systemd drop-in like:

/usr/lib/systemd/system/rpm-ostreed.service.d/
```
[Unit]
DynamicSocketPair=zincati.service
```

Then when either service starts for the first time, systemd creates a 
socketpair() and hands off one end to the activating service.  And there'd be 
an extension of sd_listen_fds() that gives me the tuple (fd, "zincati.service") 
or so?

Perhaps a pattern that can be implemented today for this is for the privileged 
helper to create an "inaccessible directory" e.g. /run/rpm-ostree/privapi (last 
component mode 0700) with a .socket unit there, and then in zincati.service 
uses WorkingDirectory=/run/rpm-ostree/privapi to traverse it and access 
/run/rpm-ostree/privapi/rpmostree.socket or so.

The main goal here is to make this communication channel truly private to the 
participating services - as opposed to e.g. exposing a DBus service or 
globally-accessible socket, since that brings in the problems of authorization 
and increases attack surface generally.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel