Bug 29393 - SSH-Zugriff verweigert, wenn viele Benutzer und Gruppen im System sind
SSH-Zugriff verweigert, wenn viele Benutzer und Gruppen im System sind
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: PAM
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.1-0-errata
Assigned To: Philipp Hahn
Stefan Gohmann
:
Depends on:
Blocks: 45039
  Show dependency treegraph
 
Reported: 2012-11-26 15:04 CET by Jan Christoph Ebersbach
Modified: 2017-07-18 19:30 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Christoph Ebersbach univentionstaff 2012-11-26 15:04:47 CET
An Ticket #2012112121000646 ist aufgefallen, dass der Aufbau der SSH-Sitzung eines Benutzers aus der Gruppe Domain Admins ohne Fehlermeldung abbricht, sobald der Benutzer sein richtiges Passwort eingibt. Hier ein Auszug aus der SSH-Sitzung:

debug1: Next authentication method: password
USER@SERVER's password: 
debug3: packet_send2: adding 48 (len 66 padlen 14 extra_pad 64)
debug2: we sent a password packet, wait for reply
Connection closed by 10.149.200.102

In der Umgebung wird das Group-Cache-File eingesetzt.

Das Problem konnte auf pam_access eingegrenzt werden, das anscheinend nicht mit einer umfangreichen /var/lib/extrausers/group-Datei zurecht kommt. Die Gruppe Domain Admins steht in dem speziellen Fall hinter der sehr großen Domain Users-Gruppe, die ca. 30000 Mitglieder hat. Verschiebt man manuell die Domain Admins-Gruppe an den Anfang der group-Datei, so funktioniert der Zugriff problemlos.

Von dem Problem sind alle Dienste, die pam_access verwenden, z.B. gdm, login und sshd. getent und id arbeiten aber weiterhin problemlos.

Es ist nicht klar ab welcher Gruppengröße das Problem auftritt.
Comment 1 Jan Christoph Ebersbach univentionstaff 2012-11-26 15:07:05 CET
In der Umgebung hat /var/lib/extrausers/group aktuell eine Größe von 3.4 MB.
Comment 2 Stefan Gohmann univentionstaff 2012-11-27 20:42:30 CET
Funktioniert es, wenn pam_access nur auf Benutzer filtert?
Comment 3 Stefan Gohmann univentionstaff 2012-11-30 07:12:11 CET
(In reply to comment #2)
> Funktioniert es, wenn pam_access nur auf Benutzer filtert?

Ich konnte es in meiner Testumgebung reproduzieren. 

Der Workaround "ucr set auth/sshd/user/Administrator=yes" war bei mir erfolgreich.

Wir sollten dazu nach dem 3.1 Release ein errata-Update veröffentlichen, da auch der Zugriff beim Joinen von UCS Systemen darüber gesteuert wird.
Comment 4 Stefan Gohmann univentionstaff 2012-11-30 07:19:04 CET
Alternativer Workaround:
 ucr set auth/sshd/restrict=false

Das stellt das 2.4 Verhalten wieder her und erlaubt den Zugriff per sshd für alle Benutzer mit gültigem Passwort.
Comment 5 Stefan Gohmann univentionstaff 2012-12-30 17:24:40 CET
Workaround existiert.
Comment 6 Philipp Hahn univentionstaff 2013-01-16 19:37:46 CET
libpam/pam_modutil_private.h defines some limits
 #define PWD_INITIAL_LENGTH     0x400
 #define PWD_ABSURD_PWD_LENGTH  0x40001
 #define PWD_LENGTH_SHIFT 4 /* 2^4 == 16 */

After 3 shifts the buffer gets over-extended to 4.194.304, which is larger than the maximum 262.145 bytes, so any group which doesn't fit into those 262 kB 
aborts the parsing process with the following message:
 [pam_modutil_getgrnam.c:pam_modutil_getgrnam(112)] grp structure took 4194336 bytes or so of memory

libpam/pam_modutil_getgrnam.c:109
    } while (length < PWD_ABSURD_PWD_LENGTH);


How to (roughly) debug this:
# Create large group
ucr set nss/group/cachefile/invalidate_interval=disabled
mv /var/lib/extrausers/group /var/lib/extrausers/group.orig
(
  echo -n Large:*:99887:
  seq -s, -f'%08.0f' 0 30000
  cat /var/lib/extrausers/group.orig
) >/var/lib/extrausers/group
# Build debug version
ucr set repository/online/{unmaintained=yes,sources=yes}
apt-get update
apt-get install build-essential
apt-get build-dep pam
apt-get source pam
cd pam-*
sed -i -e '/dh_auto_configure/s/--/& --enable-debug/' debian/rules
dpkg-buildpackage -uc -us -b
dpkg -i ../libpam0g_* ../libpam-modules_* ../libpam-modules_*
# Run test
sed -i -e /service/s/passwd/sshd/ /usr/share/doc/python-pam/examples/pamtest.py
python /usr/share/doc/python-pam/examples/pamtest.py Administrator
Comment 7 Philipp Hahn univentionstaff 2013-01-17 10:39:03 CET
Beim PAM-Modul pam_access kann jetzt per maxent=0x40001 die maximale Größe für den Gruppen-Check angepasst werden. Um einen Richtwert für die (derzeit) benötigten Größe zu bekommen, kann man folgendes Kommando aufrufen:
  getent group | wc -L
Die Option kann derzeit nicht direkt gesetzt werden, weil das UCS-Template aus univention-pam dazu keine Möglichkeit bietet. Über einen Trick geht es aber doch:
  for scope in $(grep -h ^scope /etc/univention/templates/files/etc/pam.d/* |
    sed -re 's/^scope = "([^"]+)"/\1/')
  do
    echo auth/$scope/accessfile=/etc/security/access-$scope.conf maxent=0x400001
  done | xargs -r -d'\n' ucr set

svn11310,11311, pam_1.1.1-6.1.41.201301171014
ChangeLog: svn16110,16111
\item The option \ucsName{maxent} was added to \ucsName{pam_access} to configure the maximum buffer size needed to check group membership in large environments (\ucsBug{29393}).

YAML: 2013-01-17-pam.yaml (svn16111)
Comment 8 Philipp Hahn univentionstaff 2013-01-18 10:48:55 CET
Die UCR-Templates, die pam_access.so verwenden, aus den Paketen univention-pam, univention-nagios, univention-virtual-machine-manager-daemon wurden angepasst, so daß dort nun optional die UCR-Variable "pamaccess/maxent" eingefügt wird.

UCS-3.1-1: svn38362
ChangeLog: svn16131
... The limit can be changed using the \ucsUCRV{pamaccess/maxent} ...

UCS-3.1-0-errata: svn11316
git format-patch -1 --stdout |
 filterdiff -p4 -i base/univention-pam/\* -x \*/changelog --strip=5 > patches/univention-pam/3.1-0-0-ucs/6.0.10-2-errata3.1-0/0002-Bug-29393-support-pamaccess_maxent.patch
YAML: 2013-01-18-univention-pam.yaml (svn16130)

univention-nagios und uvmm-daemon wurde noch nicht gebaut, weder für 3.1-0-errata noch für 3.1-1. Falls für eines der Pakete noch ein errata-Update für 3.1-0 fällig wird, sollten wir den Patch dann noch mit einspielen; ansonsten erfolgt das dann nur zu 3.1-1. (so abgesprochen mit Stefan)
Comment 9 Stefan Gohmann univentionstaff 2013-01-24 16:07:47 CET
OK, funktioniert soweit. Es wäre gut, wenn der Default noch etwas erhöht wird, derzeit funktioniert es bei mir mit 40.000 Benutzern (test$number) nicht:

root@master511:~# getent group foobar1 | wc -L
388904
Comment 10 Philipp Hahn univentionstaff 2013-01-24 16:33:08 CET
+       pamaccess/maxent?0x400001 \

UCS-3.1-1: svn38538, 
UCS-3.1-0errata: svn11338, univention-pam_6.0.10-2.204.201301241621
YAML: svn16179
Comment 11 Stefan Gohmann univentionstaff 2013-01-24 16:53:05 CET
(In reply to comment #10)
> +       pamaccess/maxent?0x400001 \
> 
> UCS-3.1-1: svn38538, 
> UCS-3.1-0errata: svn11338, univention-pam_6.0.10-2.204.201301241621
> YAML: svn16179

OK
Comment 12 Moritz Muehlenhoff univentionstaff 2013-01-25 10:30:38 CET
http://errata.univention.de/3.1-errata20.html
Comment 13 Moritz Muehlenhoff univentionstaff 2013-01-25 10:30:55 CET
http://errata.univention.de/3.1-errata21.html