PAM support is now integrated into ARM -current

drmozes · 05-26-2020, 10:01 AM

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.

abga · 05-26-2020, 03:20 PM

- 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
May 26 21:56:42 pi2s1 gnome-keyring-daemon[30388]: couldn't bind to control socket: /root/.cache/keyring-GEASK0/control: Permission denied
May 26 22:07:33 pi2s1 gnome-keyring-daemon[32343]: couldn't create socket directory: /back/.cache/keyring-R4JQK0: No such file or directory
May 26 22:07:33 pi2s1 gnome-keyring-daemon[32343]: couldn't bind to control socket: /back/.cache/keyring-R4JQK0/control: No such file or directory
...
May 26 22:09:44 pi2s1 gnome-keyring-daemon[1485]: couldn't create socket directory: /back/.cache/keyring-PC42K0: No such file or directory
May 26 22:09:44 pi2s1 gnome-keyring-daemon[1485]: couldn't bind to control socket: /back/.cache/keyring-PC42K0/control: No such file or directory

- /back is an external USB drive I keep mounted for backups

Code:

# mount | grep back
/dev/sda1 on /back type ext4 (rw,noatime)

- is there anything extra I need to make executable in /etc/rc.d/? Noticed some new services in the updated rc.inet2

abga · 05-26-2020, 03:49 PM

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
Login: postgres                         Name:
Directory: /back                          Shell: /bin/bash
Never logged in.
No mail.
No Plan.

P.S. Is sshd calling gnome-keyring-daemon ? I put in place the new conf file:

Code:

# grep UsePAM /etc/ssh/sshd_config
UsePAM yes

abga · 05-26-2020, 05:30 PM

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
gnome-keyring-daemon[21525]: couldn't bind to control socket: /root/.cache/keyring-7WT0K0/control: Permission denied

What's this all about? Is this gnome-keyring needed in console mode? Shall I disable it with unset GNOME_KEYRING_CONTROL in a .bashrc file ? Any "wiser" method?

mralk3 · 05-26-2020, 06:06 PM

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
May 26 17:02:11 miniship gnome-keyring-daemon[1000]: couldn't bind to control socket: /var/run/user/1000/keyring-KIMUK0/control: Permission denied
May 26 17:02:22 miniship gnome-keyring-daemon[1017]: couldn't create socket directory: /var/run/user/1000/keyring-662WK0: Permission denied
May 26 17:02:22 miniship gnome-keyring-daemon[1017]: couldn't bind to control socket: /var/run/user/1000/keyring-662WK0/control: Permission denied

EDIT: It shows in the logs every time I run sudo or su. My regular user is uid 1000.

abga · 05-26-2020, 06:34 PM

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
[D-BUS Service]
Name=org.gnome.keyring
Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

Will maybe need to go through this long explanation:
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.

abga · 05-26-2020, 07:26 PM

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
session     optional      pam_gnome_keyring.so auto_start

- just commented both lines
- then enabled back the use of PAM in sshd and bounced sshd

Code:

# grep UsePAM /etc/ssh/sshd_config
UsePAM yes

Now my syslog stays clean for both ssh logins and su - operations. Questions still remain:
- 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

mralk3 · 05-26-2020, 07:50 PM

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.

abga · 05-27-2020, 12:30 AM

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.

drmozes · 05-27-2020, 05:44 AM

Quote:

Originally Posted by mralk3

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.

I can replicate this on x86_64 too.

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)
May 27 10:05:31 zippy login: gkr-pam: unable to locate daemon control file

But I can't yet see any adverse effects from it,. but I suspect that there will be.

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.

drmozes · 05-27-2020, 07:32 AM

[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
[D-BUS Service]
Name=org.gnome.keyring
Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

I've not made edits to the /etc/pam.d files, but I added ',ssh' to the components list of the dbus config file you've pasted above.

Code:

Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets,ssh

This seems to quell the messages about sockets, but I'm just hacking on it at the moment.

Quote:

Will maybe need to go through this long explanation:
https://itnext.io/what-is-linux-keyr...s-349df9411e67

Thanks, I'll have a read about this.

mralk3 · 05-27-2020, 01:00 PM

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*

abga · 05-27-2020, 05:47 PM

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
session     optional      pam_gnome_keyring.so auto_start

- checked the available doc (inconsistent, mostly operational stuff) and learned that the actual Slackware implementation should be OK:
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:

- When run with the --login option, gnome-keyring-daemon expects a password on it's stdin. All characters until stdin closes are considered part of the password.
- When run with the --login option, gnome-keyring-daemon does not fully initialize. It expects to be initialized later by calling another gnome-keyring-daemon with the --start option.

Code:

# ps axu | grep gnome-keyring-daemon | grep -v grep
test       22218  0.0  0.4  29216  3904 ?        Sl   23:09   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

- failed to find any official doc on the d-bus integration of gnome keyring

- 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)
strace: Process 22218 attached with 3 threads
[pid 22218] 23:14:04 unlink("/home/test/.cache/keyring-TCM8K0/control") = 0
[pid 22218] 23:14:04 rmdir("/home/test/.cache/keyring-TCM8K0") = 0
[pid 22218] 23:14:04 +++ exited with 0 +++
[pid 22218] 23:14:04 +++ exited with 0 +++
23:14:04 +++ exited with 0 +++

2. d-bus only shows that /var/run/console/test doesn't exist, discussed here (& didn't read it, cannot care less about the dbus stuff):
https://lists.freedesktop.org/archiv...ne/017224.html

Code:

# strace -t -e trace=file -fp $(pidof dbus-daemon)
strace: Process 686 attached

23:09:09 access("/var/run/console/test", F_OK) = -1 ENOENT (No such file or directory)
23:09:09 openat(AT_FDCWD, "/proc/22218/cmdline", O_RDONLY|O_LARGEFILE) = 13
# ps axu | grep gnome-keyring-daemon | grep -v grep
test       22218  0.0  0.4  29216  3904 ?        Sl   23:09   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

- running multiple tests I got a nice collection of crap in my /root/.cache/ folder and noticed that I only get error messages related to
/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-*
drwx------ 2 root root 4096 May 27 22:49 /root/.cache/keyring-BADAL0/
drwx------ 2 root root 4096 May 27 22:52 /root/.cache/keyring-QFX1K0/
drwx------ 2 root root 4096 May 27 22:53 /root/.cache/keyring-USCUK0/
drwx------ 2 root root 4096 May 27 22:49 /root/.cache/keyring-YLXSK0/

My personal conclusion & opinion is that I had a very happy life without this gnome keyring thingy and that I'll never consider using its "features", that's potentially weakening the authentication security model.
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

abga · 05-27-2020, 09:13 PM

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
su[30379]: + /dev/pts/1 test:root
su[30379]: pam_unix(su:session): session opened for user root by test(uid=1000)
su[30379]: gkr-pam: unable to locate daemon control file
su[30379]: gkr-pam: gnome-keyring-daemon started properly
su[30379]: pam_unix(su:session): session closed for user root

- then, after the restart, I started getting such records:

Code:

sshd[1429]: pam_unix(sshd:session): session opened for user test by (uid=0)
sshd[1429]: gkr-pam: unable to locate daemon control file
sshd[1429]: gkr-pam: gnome-keyring-daemon started properly
su[1546]: Successful su for root by test
su[1546]: + /dev/pts/0 test:root
su[1546]: pam_unix(su:session): session opened for user root by test(uid=1000)
su[1546]: The gnome keyring socket is not owned with the same credentials as the user login: /home/test/.cache/keyring-GM32K0/control
su[1546]: gkr-pam: couldn't unlock the login keyring.

- here are the records (same just repeating) related to the latest tests/investigation (post #13)

Code:

sshd[22821]: pam_unix(sshd:session): session opened for user test by (uid=0)
sshd[22821]: gkr-pam: unable to locate daemon control file
sshd[22821]: gkr-pam: gnome-keyring-daemon started properly
su[22859]: Successful su for root by test
su[21538]: + /dev/pts/1 test:root
su[21538]: pam_unix(su:session): session opened for user root by test(uid=1000)
su[21538]: The gnome keyring socket is not owned with the same credentials as the user login: /home/test/.cache/keyring-QXDYK0/control
su[21538]: gkr-pam: couldn't unlock the login keyring.

- gkr-pam: unable to locate daemon control file - looks unresolved:
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

gegechris99 · 05-28-2020, 01:35 AM

Quote:

Originally Posted by abga

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

A more appropriate approach is to append character - at the beginning of the lines that bother you in /etc/pam.d/system-auth.
The reason is explained in this thread issue with PAM.