Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

afpd: systemd-logind ReleaseSession rejected by dbus-daemon #361

Closed
RichieB2B opened this issue Jul 2, 2023 · 18 comments
Closed

afpd: systemd-logind ReleaseSession rejected by dbus-daemon #361

RichieB2B opened this issue Jul 2, 2023 · 18 comments
Assignees

Comments

@RichieB2B
Copy link
Contributor

As reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106

I am using netatalk for time machine backups. After every session I see this line in /var/log/auth.log

2023-07-01T22:31:47.223949+02:00 my-server dbus-daemon[1538889]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.153636" (uid=145 pid=2690475 comm="/usr/sbin/afpd -d -F /etc/netatalk/afp.conf") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=1538900 comm="/lib/systemd/systemd-logind")

Today I finally found the solution at https://bugs.launchpad.net/ubuntu/+source/netatalk/+bug/1538004

It is simple really, in /etc/pam.d/netatalk replace this line:

@include common-session

with this line:

@include common-session-noninteractive

This fixed the issue for me.

@rdmark
Copy link
Member

rdmark commented Jul 2, 2023

Thanks for filing this! Since the macro suggests that this particular branch applies to SuSE in addition to Debian, let me run a quick test on openSUSE to make sure this works cross-distro.

@rdmark
Copy link
Member

rdmark commented Jul 4, 2023

Tested on Debian Bookworm & openSUSE Tumbleweed. Works as expected.

Next up is to back port this to the 2.2 branch.

@rdmark
Copy link
Member

rdmark commented Aug 5, 2023

2.2 branch PR #367

@rdmark rdmark closed this as completed Aug 7, 2023
@mwmahlberg
Copy link

This also applies for Fedora 38 at least. Using it on a Raspi, so I can only confirm this for the arm side of things.

@rdmark rdmark reopened this Nov 1, 2023
@rdmark
Copy link
Member

rdmark commented Nov 1, 2023

@mwmahlberg Can you tell me the location and contents of the pam.d auth dir?

This is the current RH/Fedora logic:

        dnl RHEL/FC
        elif test -f "$pampath/system-auth" ; then
           PAM_DIRECTIVE=include
           PAM_AUTH=system-auth
           PAM_ACCOUNT=system-auth
           PAM_PASSWORD=system-auth
           PAM_SESSION=system-auth

We need to figure out if the non-interactive configuration sits in that same file, or if there's another one we should import instead.

@rdmark
Copy link
Member

rdmark commented Nov 2, 2023

I booted into Fedora Linux Asahi Remix (39 based) on my MacBook to investigate. This is what I see.

dmark@daniel-macbookpro:/etc/pam.d$ cat system-auth 
# Generated by authselect
# Do not modify this file manually, use authselect instead. Any user changes will be overwritten.
# You can stop authselect from managing your configuration by calling 'authselect opt-out'.
# See authselect(8) for more details.

auth        required                                     pam_env.so
auth        required                                     pam_faildelay.so delay=2000000
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
auth        sufficient                                   pam_unix.so nullok
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
auth        sufficient                                   pam_sss.so forward_pass
auth        required                                     pam_deny.so

account     required                                     pam_unix.so
account     sufficient                                   pam_localuser.so
account     sufficient                                   pam_usertype.so issystem
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required                                     pam_permit.so

password    requisite                                    pam_pwquality.so local_users_only
password    sufficient                                   pam_unix.so yescrypt shadow nullok use_authtok
password    [success=1 default=ignore]                   pam_localuser.so
password    sufficient                                   pam_sss.so use_authtok
password    required                                     pam_deny.so

session     optional                                     pam_keyinit.so revoke
session     required                                     pam_limits.so
-session    optional                                     pam_systemd.so
session     [success=1 default=ignore]                   pam_succeed_if.so service in crond quiet use_uid
session     required                                     pam_unix.so
session     optional                                     pam_sss.so

There's no equivalent "non-interactive" profile that I can see, unlike Debian. Some other solution may be required.

@rdmark
Copy link
Member

rdmark commented Nov 3, 2023

For reference, this is the diff between interactive and non-interactive pam configs on Debian.

dmark@macuntu:/etc/pam.d$ diff -u common-session common-session-noninteractive 
--- common-session	2023-10-01 23:52:52.307711006 +0000
+++ common-session-noninteractive	2023-10-01 23:52:52.407696570 +0000
@@ -1,9 +1,10 @@
 #
-# /etc/pam.d/common-session - session-related modules common to all services
+# /etc/pam.d/common-session-noninteractive - session-related modules
+# common to all non-interactive services
 #
 # This file is included from other service-specific PAM config files,
 # and should contain a list of modules that define tasks to be performed
-# at the start and end of interactive sessions.
+# at the start and end of all non-interactive sessions.
 #
 # As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
 # To take advantage of this, it is recommended that you configure any
@@ -26,5 +27,4 @@
 session optional			pam_umask.so
 # and here are more per-package modules (the "Additional" block)
 session	required	pam_unix.so 
-session	optional	pam_systemd.so 
 # end of pam-auth-update config

@rdmark
Copy link
Member

rdmark commented Nov 3, 2023

So in conclusion, the generated netatalk.pam on Fedora needs to not have this line, I think:

-session    optional                                     pam_systemd.so

However, the way we have implemented this presently is to blanket import system-auth.

#%PAM-1.0
auth     include system-auth
account  include system-auth
password include system-auth
session  include system-auth

@rdmark
Copy link
Member

rdmark commented Nov 3, 2023

@knight-of-ni Do you have any insights into how Fedora deals with PAM configuration variants like this? Do you have something in your rpm packaging scripts that handles this?

In fact, from my brief testing on Fedora Remix Asahi Linux 39, I can't see that our install target even installs the generated netatalk PAM config...

@knight-of-ni
Copy link
Contributor

Yep. The pam config you posted earlier is included as an additional source file in the rpm specfile:
https://src.fedoraproject.org/rpms/netatalk/blob/rawhide/f/netatalk.spec#_60
https://src.fedoraproject.org/rpms/netatalk/blob/rawhide/f/netatalk.pam-system-auth

This file predates my time as the Netatalk package maintainer. I never really looked too closely at it.
If it helps, feel free to include it in the upstream project.

@rdmark
Copy link
Member

rdmark commented Nov 4, 2023

@knight-of-ni Thanks for sharing, it is interesting to see how this was tackled downstream!

I'm a bit hesitant to manage a custom PAM config file in the upstream project. I think there's a bigger risk it goes stale here than in the downstream package script.

One idea though... I wonder if it's possible to fit an equivalent configuration into the existing template: https://github.com/Netatalk/netatalk/blob/main/config/pam/netatalk.tmpl

Something worth investigating...

@mwmahlberg
Copy link

@rdmark Sorry for the late reply.

$ ssh raspi -- cat /etc/pam.d/netatalk
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
-session    optional     pam_ck_connector.so

Interestingly, this seems to look quite a bit different to what you get. I am not exactly a PAM expert, so you might need to guide me here.

$ ssh raspi.fritz.box -- authselect current
Profile ID: sssd
Enabled features:
- with-silent-lastlog

This seems to indicate the use of sssd, which in turn does not run because of

Nov 06 04:58:24 raspi systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.

To my understanding the sssd profile only makes sense in an environment with centralized IDP.
Now the interesting part is that this is a default installation of Fedora 38 from the qcow-image for arm64 - and I didn't even plan to use a centralized IDP on that machine. As per the linked doc, I assume the difference between your and my output of the pam config is due to modifications conducted by auth-select, though I might be wrong here.

I'd rather not change the auth-select profile on the installation, unless absolutely necessary. Could you check what your auth-select profile is on your Fedora 39?

@rdmark
Copy link
Member

rdmark commented Nov 7, 2023

@mwmahlberg Thanks for sharing! So what you have there, is exactly the template used by the rpm packaging recipe that is linked in the previous comment. So this suggests that you installed netatalk via the rpm, and not from source. Is this accurate?

The reason our netatalk pam config is different is most likely because I installed from source in this particular instance.

Anyways, if the pam behavior on Fedora is the same as on Debian (which I would expect) it means that this line... session include system-auth in the netatalk pam config imports system-auth and which has this line... -session optional pam_systemd.so which is the one that would trigger the "rejected send messages".

Either the system pam config needs to be modified (on the fly?) or the netatalk pam config for the rpm package needs to be updated to work properly with today's Fedora default. More research is required...

@mwmahlberg
Copy link

mwmahlberg commented Nov 7, 2023

@rdmark Indeed, I installed it from an RPM. Actually, mid-term I think of utilizing cockpit to provide a UI for setting up TimeMachine Backups. Which basically means a UI for netatalk.

@rdmark @knight-of-ni In this case, it should be easy enough to test, as far as I can see it:

  1. Copy over the session contents of system-auth into the netatalk pam.d module.
  2. Remove (?) the offending systemd line from the result.
  3. Restart netatalk daemon and check for functionality.

I will try this as soon as possible and will let you know the results.

@rdmark
Copy link
Member

rdmark commented Nov 7, 2023

@mwmahlberg Cockpit looks neat!

We do have a Webmin module for netatalk which I've recently been improving upon. It works fairly well for basic administration of netatalk, including enabling TM for a volume. It does not, however, create dirs and set permissions on the dir for you. You have to prepare a dir elsewhere. I assume your use case is to do the administration end-to-end in the Web UI?

@rdmark
Copy link
Member

rdmark commented Nov 19, 2023

@mwmahlberg Since the original issue for Debian was resolved and the solution for Fedora looks to be quite different, let me close this ticket again. May I ask you to create a new ticket for the Fedora situation?

@rdmark rdmark closed this as completed Nov 19, 2023
@mwmahlberg
Copy link

@rdmark

@mwmahlberg Cockpit looks neat!

We do have a Webmin module for netatalk which I've recently been improving upon. It works fairly well for basic administration of netatalk, including enabling TM for a volume. It does not, however, create dirs and set permissions on the dir for you. You have to prepare a dir elsewhere. I assume your use case is to do the administration end-to-end in the Web UI?

Indeed it is. The idea is to have a small Fedora distribution for converting a Raspi into a fully fledged TimeMachine and then some (for example Storage/LTS on SSE S3 instead of a local disk). I very much assume I am not the only one with that use case. The neat thing about Cockpit is that one has a bridge for about any operation one needs to do. In a local network, the security risk of that is (imho) acceptable.

@mwmahlberg
Copy link

@mwmahlberg Since the original issue for Debian was resolved and the solution for Fedora looks to be quite different, let me close this ticket again. May I ask you to create a new ticket for the Fedora situation?

Will do later this day or tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

No branches or pull requests

4 participants