PAM support is now integrated into ARM -current
Hello
PAM support has been integrated into -current and is now available. It seems fine to me, but if there are any issues, please reply to this thread. Cheers s. |
- some noise captured in syslog after the updates & reboot. The system is headless and I'm not able to hook it on HDMI ATM.
Code:
May 26 21:56:42 pi2s1 gnome-keyring-daemon[30388]: couldn't create socket directory: /root/.cache/keyring-GEASK0: Permission denied Code:
# mount | grep back |
Just noticed, the user used for ssh-ing the system starts: /usr/bin/gnome-keyring-daemon --daemonize --login
And some subfolder of /back is defined as home & DB store for the user postgres (I used it once as DB storage). Code:
# finger postgres Code:
# grep UsePAM /etc/ssh/sshd_config |
Hurray! Got rid of that thing, just commented "UsePAM yes" in /etc/ssh/sshd_config and bounced sshd.
But there are also some other ways to get rid of it: https://askubuntu.com/questions/2432...ing-in-xubuntu (nice, ended up looking for help in *buntu info sources ...) EDIT: Err, I didn't. After logging in through ssh with a normal user, when I issue "su -" and switch to root, I still get these thrown in syslog: Code:
gnome-keyring-daemon[21525]: couldn't create socket directory: /root/.cache/keyring-7WT0K0: Permission denied |
I am seeing similar gnome-keyring output, except there is no mention about a mount point. I have an external usb drive connected, but it is not mounted. On a rpi 4.
some output: Code:
May 26 17:02:11 miniship gnome-keyring-daemon[1000]: couldn't create socket directory: /var/run/user/1000/keyring-KIMUK0: Permission denied |
It looks like "the old friend" d-bus is launching gnome-keyring-daemon, that's for the "who/what".
Code:
# cat /usr/share/dbus-1/services/org.gnome.keyring.service https://itnext.io/what-is-linux-keyr...s-349df9411e67 As for the "why" it tries & cannot write into /root/.cache/ & what has to do with the /back mount point, I still have no clue. |
Thanks to the following Arch wiki article I learned how to put gnome keyring to sleep for good - just as a temporary workaround:
https://wiki.archlinux.org/index.php...ing#PAM_method - in Slackware -current it is enabled in /etc/pam.d/system-auth Code:
auth optional pam_gnome_keyring.so - then enabled back the use of PAM in sshd and bounced sshd Code:
# grep UsePAM /etc/ssh/sshd_config - if the gnome keyring is used as a critical component in the Slackware PAM implementation. If positive, disabling it is not an option! - why it tries and fails to write into /root/.cache/ & the other mount point? I was only able to find a clue here: https://github.com/atom/node-keytar/...ment-467108749 |
I do not have an x86_64 install of current on my laptop to check if this issue appears in all -current or just SlackwareARM. I am very interested to look and compare. As of right now, I am running 14.2 on my laptop, everything else I own now is all ARM devices.
|
Neither do I, running -current only on my armv7 Raspberries because of the performance gain (compared with the armv6 SF stable).
Some of the other ARM users could check what's reported here on their available x86 -current systems. If no replies/interests, I'll maybe start a thread in the main forum and link this discussion. That clue I found on github (post #7) mentions a timeout as being a potential cause. The lower performance of these ARM boards could cause such delays/timeouts. |
Quote:
There is also a warning that exists on x86_64 and ARM, which you get when logging in: Code:
May 27 10:05:31 zippy login: pam_unix(remote:session): session opened for user root by (uid=0) The Slackware team's aware of this issue now. Can you move this thread to the main forum for more attention, as was suggested? More eyes the better. |
[QUOTE=abga;6127671]It looks like "the old friend" d-bus is launching gnome-keyring-daemon, that's for the "who/what".
Code:
# cat /usr/share/dbus-1/services/org.gnome.keyring.service Code:
Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets,ssh Quote:
|
Well here goes, installing pam on my production router/gateway. I haven't found any other issue on the pi4 except what was reported in this thread. I have some spare hardware I can plug in if something goes wrong. Should be fine. *crosses fingers*
|
Just spent some time to do some more tests on this gnome keyring thingy and try to understand why I get those lines in syslog.
- un-commented the lines in /etc/pam.d/system-auth and logged out: Code:
auth optional pam_gnome_keyring.so https://wiki.gnome.org/Projects/Gnom.../RunningDaemon https://wiki.gnome.org/Projects/GnomeKeyring/Pam/Manual https://wiki.gnome.org/Projects/GnomeKeyring/Pam However, it shows started with --login and according to the docs, that will expect some input Quote:
Code:
# ps axu | grep gnome-keyring-daemon | grep -v grep - next, ran some tests trying to catch who&why is trying to access the /root/.cache/keyring* and why I get the permission denied errors - used the test user to remotely connect through ssh and traced both gnome-keyring-daemon & dbus-daemon looking for opening files: 1. gnome-keyring-daemon, which is launched from /etc/pam.d/system-auth doesn't look to try to access (write) directly anything in /root/ and it times out after 5 minutes: Code:
# strace -f -t -e trace=file -fp $(pidof gnome-keyring-daemon) https://lists.freedesktop.org/archiv...ne/017224.html Code:
# strace -t -e trace=file -fp $(pidof dbus-daemon) /root/.cache/ now and only when I connect remotely through ssh with the user test. Afterwards, if I switch to root "su -", there's nothing reported in syslog, weird. Also nothing related to /back/.cache/ anymore. Code:
# ls -ald /root/.cache/keyring-* https://bugs.launchpad.net/ubuntu/+s...g/+bug/1780365 Therefore, I'll disable it and suggest in the Requests for -current thread to move it as optional package. Let the ones who really need it break their heads trying to make sense of it :) |
I didn't inspect /var/log/secure until now and just noticed:
- yesterday, just after the PAM-ification (updates on -current) and before restarting the system (was already logged in with ssh): Code:
su[30379]: Successful su for root by test Code:
sshd[1429]: pam_unix(sshd:session): session opened for user test by (uid=0) Code:
sshd[22821]: pam_unix(sshd:session): session opened for user test by (uid=0) https://gitlab.gnome.org/GNOME/gnome...ng/-/issues/28 https://bugs.archlinux.org/task/62140 - The gnome keyring socket is not owned with the same credentials as the user login ... a patch from 2014 !? https://bugzilla.gnome.org/show_bug.cgi?id=733418 - gkr-pam: couldn't unlock the login keyring - could be related to the ones above https://bbs.archlinux.org/viewtopic.php?id=245171 https://bugs.archlinux.org/task/62140 There are some fixes I found where setting up Gnome Keyring related environment variables fixed some of the reported issues. I haven't found any collection/doc on them, just the Gnome Keyring WiKi mentioning some (that appear to be set & used by the Gnome Keyring itself): https://wiki.gnome.org/Projects/Gnom...g/Distributors - section: Environment Variables On a positive side, a nice diagram (for a beta software)! https://wiki.gnome.org/Projects/Gnom...g/Architecture I declare myself Gnome Keyring "healed" (hopefully), as I commented back the pam_gnome_keyring.so related lines from /etc/pam.d/system-auth and also removed (backed up) the org.gnome.keyring* files from /usr/share/dbus-1/services/ and bounced d-bus ;) |
Quote:
The reason is explained in this thread issue with PAM. |
All times are GMT -5. The time now is 02:07 PM. |