"su -" zegt: Incorrect password... zonder te vragen - Linux en overige clients

donderdag 19 mei 2005 21:50

Acties:

Voor al uw hersenspinsels

Topicstarter

Hopelijk kan iemand mij helpen met het volgende probleem. Het gaat om een AMD64 Opteron dualbak met Gentoo Linux erop.

Het probleem is dat ik niet kan su'en. (sudo werkt wel.) Als ik zeg: su -, dan zegt hij onmiddelijk terug: Incorrect password. Ik krijg niet eens de kans om er een in te typen

Mijn user zit in de group wheel (secondary group, met -G, maar ook als primary werkt het niet). Systemwide staat de pam USE flag aan, dus ik neem aan dat su ook PAM gebruikt.

De permissies op /bin/su zijn goed:

code:

1	-rwsr-xr-x 1 root root 30472 May 19 20:27 /bin/su

/etc/pam.d/su ziet er zo uit:

code:

#%PAM-1.0

auth       sufficient   /lib/security/pam_rootok.so

# If you want to restrict users begin allowed to su even more,
# create /etc/security/suauth.allow (or to that matter) that is only
# writable by root, and add users that are allowed to su to that
# file, one per line.
#auth       required     /lib/security/pam_listfile.so item=ruser sense=allow onerr=fail file=/etc/security/suauth.allow

# Uncomment this to allow users in the wheel group to su without
# entering a passwd.
#auth       sufficient   /lib/security/pam_wheel.so use_uid trust

# Alternatively to above, you can implement a list of users that do
# not need to supply a passwd with a list.
#auth       sufficient   /lib/security/pam_listfile.so item=ruser sense=allow onerr=fail file=/etc/security/suauth.nopass

# Comment this to allow any user, even those not in the 'wheel'
# group to su
auth       required     /lib/security/pam_wheel.so use_uid

auth       required     /lib/security/pam_stack.so service=system-auth

account    required     /lib/security/pam_stack.so service=system-auth

password   required     /lib/security/pam_stack.so service=system-auth

session    required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_env.so
session    optional     /lib/security/pam_xauth.so

Mocht het uitmaken, dan hier ook /etc/login.defs:

code:

#
# /etc/login.defs - Configuration control definitions for the login package.
#
# All items are optional - if not specified then the described action or
# option will be inhibited.
#
# Comment lines (lines beginning with "#") and blank lines are ignored.
#

#
# Delay in seconds before being allowed another attempt after a login failure
#
FAIL_DELAY              3

#
# Enable logging and display of /var/log/faillog login failure info.
#
FAILLOG_ENAB            yes

#
# Enable display of unknown usernames when login failures are recorded.
#
LOG_UNKFAIL_ENAB        no

#
# Enable logging and display of /var/log/lastlog login time info.
#
LASTLOG_ENAB            yes

#
# If defined, ":" delimited list of "message of the day" files to
# be displayed upon login.
#
MOTD_FILE       /etc/motd
#MOTD_FILE      /etc/motd:/usr/lib/news/news-motd

#
# If defined, file which maps tty line to TERM environment parameter.
# Each line of the file is in a format something like "vt100  tty01".
#
TTYTYPE_FILE    /etc/ttytype

#
# If defined, login failures will be logged here in a utmp format.
# last, when invoked as lastb, will read /var/log/btmp, so...
#
FTMP_FILE       /var/log/btmp

#
# If defined, file which inhibits all the usual chatter during the login
# sequence.  If a full pathname, then hushed mode will be enabled if the
# user's name or shell are found in the file.  If not a full pathname, then
# hushed mode will be enabled if the file exists in the user's home directory.
#
HUSHLOGIN_FILE  .hushlogin
#HUSHLOGIN_FILE /etc/hushlogins

#
# The default PATH settings.
#
ENV_PATH                /usr/local/bin:/usr/bin:/bin

#
# The default PATH settings for root:
#
ENV_ROOTPATH            /sbin:/bin:/usr/sbin:/usr/bin

#
# The default PATH settings when su'ing to root:
#
ENV_SUPATH              /sbin:/bin:/usr/sbin:/usr/bin

#
# Terminal permissions
#
#       TTYGROUP        Login tty will be assigned this group ownership.
#       TTYPERM         Login tty will be set to this permission.
#
# If you have a "write" program which is "setgid" to a special group
# which owns the terminals, define TTYGROUP to the group number and
# TTYPERM to 0620.  Otherwise leave TTYGROUP commented out and assign
# TTYPERM to either 622 or 600.
#
TTYGROUP        tty
TTYPERM         0600

#
# Password aging controls:
#
#       PASS_MAX_DAYS   Maximum number of days a password may be used.
#       PASS_MIN_DAYS   Minimum number of days allowed between password changes.
#       PASS_MIN_LEN    Minimum acceptable password length.
#       PASS_WARN_AGE   Number of days warning given before a password expires.
#
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    5
PASS_WARN_AGE   7

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN                  1000
UID_MAX                 60000

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN                   100
GID_MAX                 60000

#
# Max number of login retries if password is bad
#
LOGIN_RETRIES        3

#
# Max time in seconds for login
#
LOGIN_TIMEOUT           60

#
# Require password before chfn/chsh can make any changes.
#
CHFN_AUTH               yes

#
# Which fields may be changed by regular users using chfn - use
# any combination of letters "frwh" (full name, room number, work
# phone, home phone).  If not defined, no changes are allowed.
# For backward compatibility, "yes" = "rwh" and "no" = "frwh".
#
CHFN_RESTRICT           rwh

Overigens is, voor zover ik weet, sinds de installatie niets aan deze files veranderd.

Wat ook vreemd is zijn de volgende meldingen in de logs, telkens als ik probeer te su'en:

code:

May 19 21:49:28 [su] PAM unable to dlopen(/lib/security/pam_rootok.so)
May 19 21:49:28 [su] PAM [dlerror: /lib/security/pam_rootok.so: cannot open shared object file: No such file or directory]
May 19 21:49:28 [su] PAM adding faulty module: /lib/security/pam_rootok.so
May 19 21:49:28 [su] PAM unable to dlopen(/lib/security/pam_wheel.so)
May 19 21:49:28 [su] PAM [dlerror: /lib/security/pam_wheel.so: cannot open shared object file: No such file or directory]
May 19 21:49:28 [su] PAM adding faulty module: /lib/security/pam_wheel.so
May 19 21:49:28 [su] PAM unable to dlopen(/lib/security/pam_stack.so)
May 19 21:49:28 [su] PAM [dlerror: /lib/security/pam_stack.so: cannot open shared object file: No such file or directory]
May 19 21:49:28 [su] PAM adding faulty module: /lib/security/pam_stack.so
May 19 21:49:28 [su] PAM unable to dlopen(/lib/security/pam_env.so)
May 19 21:49:28 [su] PAM [dlerror: /lib/security/pam_env.so: cannot open shared object file: No such file or directory]
May 19 21:49:28 [su] PAM adding faulty module: /lib/security/pam_env.so
May 19 21:49:28 [su] PAM unable to dlopen(/lib/security/pam_xauth.so)
May 19 21:49:28 [su] PAM [dlerror: /lib/security/pam_xauth.so: cannot open shared object file: No such file or directory]
May 19 21:49:28 [su] PAM adding faulty module: /lib/security/pam_xauth.so
May 19 21:49:28 [su] PAM unable to dlopen(/lib/security/pam_deny.so)
May 19 21:49:28 [su] PAM [dlerror: /lib/security/pam_deny.so: cannot open shared object file: No such file or directory]
May 19 21:49:28 [su] PAM adding faulty module: /lib/security/pam_deny.so

De genoemde files zijn echter wel aanwezig en leesbaar...

Wie heeft een idee waar dit probleem door veroorzaakt wordt, en hoe ik het oplos?

Maker van Taekwindow; verplaats en resize je vensters met de Alt-toets!

donderdag 19 mei 2005 22:11

Acties:

zAo

GPLv2 Fanboy

Kun je wel su-en naar andere users? Heb je geprobeert het password opnieuw te zetten met `sudo passwd root`?
Wat krijg je als je `sudo su -` doet?

donderdag 19 mei 2005 23:02

Acties:

WildernessChild

Voor al uw hersenspinsels

Topicstarter

Het root-wachtwoord is gewoon goed, want sudo werkt (voor een extra laag beveiliging laat ik sudo om het root-wachtwoord vragen, en dat werkt). "sudo su -" gaat dus ook goed.

Maker van Taekwindow; verplaats en resize je vensters met de Alt-toets!

vrijdag 20 mei 2005 00:52

Acties:

_JGC_

Je logs zeggen het al, die PAM modules deugen niet. Draai eens ldd erover om te kijken of alle libs wel bestaan die nodig zijn voor die modules.

vrijdag 20 mei 2005 16:44

Acties:

Wilke

Het lijkt er inderdaad op (zoals _JGC_ al zegt) dat er in de PAM-modules iets mis gaat. De grote vraag is nu natuurlijk, welk pakket moet je opnieuw installeren om dat te herstellen? En verder, was dit al zo sinds de installatie, of is het 'ineens' gekomen?

Goede topicstart btw, hier heb je tenminste iets aan om te zoeken wat nou eigenlijk precies het probleem is

vrijdag 20 mei 2005 16:50

Acties:

Shuriken

Life is all about priorities

Ik bovenstaande PAM errors ook wel eens gezien op machines die hun Max Open Files bereikt hebben.

Dus dat zou ik voor de zekerheid ook maar even checken. cat /proc/sys/fs/file-nr

Tweede waarde is de nog vrije file descriptors.

Hier staat uitgelegd hoe je het kan verhelpen: http://www.netadmintools.com/art295.html

[ Voor 39% gewijzigd door Shuriken op 20-05-2005 16:53 ]

I rather have a bottle in front of me, then a frontal lobotomie

zondag 22 mei 2005 13:56

Acties:

WildernessChild

Voor al uw hersenspinsels

Topicstarter

Shuriken schreef op vrijdag 20 mei 2005 @ 16:50:
Ik bovenstaande PAM errors ook wel eens gezien op machines die hun Max Open Files bereikt hebben.

Dus dat zou ik voor de zekerheid ook maar even checken. cat /proc/sys/fs/file-nr

Tweede waarde is de nog vrije file descriptors.

Hier staat uitgelegd hoe je het kan verhelpen: http://www.netadmintools.com/art295.html

Shuriken is een held $_/-\o_$

code:

$ cat /proc/sys/fs/file-nr
5400    0       203584
$ cat /proc/sys/fs/file-max
203584

Ik kan het maximum wel gaan verhogen, maar het lijkt me sowieso niet gezond dat er meer dan 200.000 file descriptors in gebruik zijn. Blijven er dus twee vragen over:

Hoe kan ik een overzicht krijgen van het aantal file descriptors per proces?
Hoe had ik er zelf achter kunnen komen dat hier het probleem zat?

Edit 1: volgens /proc hebben we hooguit 5.000 file descriptors open:

code:

1 2	find /proc -name fd \| xargs ls \| wc -l 4587

Het proces met de meeste file descriptors is MySQL, en dat lijkt me legitiem, aangezien het een webserver is en er zo'n 150 databases op draaien.

Zouden er file descriptors kunnen zijn die niet langer eigendom zijn van een draaiend proces? Zo ja, hoe ruim ik die dan op (liefst zonder reboot)?

Edit 2: het wordt nog vreemder:

code:

1
2
3

$ echo 1000000 > file-max
$ cat file-nr
5400    0       1000000

Het tweede getal is nog steeds 0... en ook werkt su nog niet

Edit 3: tijdens het draaien van het volgende perl-scriptje verandert er helemaal niets aan /proc/sys/fs/file-nr, terwijl dat volgens deze Usenet-post wel zou moeten:

code:

1	perl -e 'for(my $FH=11; $FH<111; $FH++) { open("FILE_HANDLE${FH}", ">/dev/null") \|\| die "$!"; sleep(1); }'

offtopic:
[quote]Wilke schreef op vrijdag 20 mei 2005 @ 16:44:
Goede topicstart btw, hier heb je tenminste iets aan om te zoeken wat nou eigenlijk precies het probleem is :)[/quote]
Thanks

[ Voor 40% gewijzigd door WildernessChild op 22-05-2005 14:53 ]

Maker van Taekwindow; verplaats en resize je vensters met de Alt-toets!

zondag 22 mei 2005 16:31

Acties:

Verwijderd

Zit je gebruiker in de groep "wheel"?

Lees ik er nu toch wel over

, geen hulp van mij dus, sorry!

[ Voor 59% gewijzigd door Verwijderd op 22-05-2005 16:42 ]

dinsdag 24 mei 2005 08:38

Acties:

WildernessChild

Voor al uw hersenspinsels

Topicstarter

Als ik het goed begrijp, is het niet erg dat het tweede getal 0 is, zolang het eerste maar niet gelijk wordt aan het derde. Het eerste getal is namelijk het aantal gealloceerde file descriptors, en dat kan gewoon verhoogd worden. Klopt deze redenatie?

En zo ja, wat is er dan mis?

De suggestie van _JGC_ (niet bestaande libraries) levert helaas ook niets op; alle PAM-modules zijn afhankelijk van twee libraries die gewoon bestaan (libc en tls), en het ook wel doen omdat ssh wel werkt.

Maker van Taekwindow; verplaats en resize je vensters met de Alt-toets!

woensdag 25 mei 2005 01:57

Acties:

Verwijderd

WildernessChild schreef op donderdag 19 mei 2005 @ 21:50:
Wat ook vreemd is zijn de volgende meldingen in de logs, telkens als ik probeer te su'en:
[hele sloot met logmeldingen]

Dit is de eerste aanwijsbare fout. Hoe zit het met die libraries? Hebben ze execute permissies? Zijn het mischien symlinks naar niet-bestaande libraries? Ik zie niet in waarom je pam een probleem zou moeten hebben met open files btw. Zelf denk ik dat je, zoals JGC ook al zegt, een probleem met je pam modules hebt ...

Iig zou ik proberen om a) su te recompilen en b) pam te recompilen..

[ Voor 10% gewijzigd door Verwijderd op 25-05-2005 02:00 ]

woensdag 25 mei 2005 10:43

Acties:

WildernessChild

Voor al uw hersenspinsels

Topicstarter

Libraries bestaan, en de permissies zijn goed:

code:

$ ls -l /lib/security/
total 2293
-rwxr-xr-x  1 root root  19880 May 19 20:33 pam_access.so
-rwxr-xr-x  1 root root   8144 May 19 20:33 pam_chroot.so
-rwxr-xr-x  1 root root 116600 May 19 20:33 pam_console.so
-rwxr-xr-x  1 root root  99952 May 19 20:33 pam_console_apply_devfsd.so
-rwxr-xr-x  1 root root  47504 May 19 20:33 pam_cracklib.so
-rwxr-xr-x  1 root root   8320 May 19 20:33 pam_debug.so
-rwxr-xr-x  1 root root   4976 May 19 20:33 pam_deny.so
-rwxr-xr-x  1 root root  13104 May 19 20:33 pam_env.so
drwxr-xr-x  2 root root     80 May 19 20:33 pam_filter
-rwxr-xr-x  1 root root  12632 May 19 20:33 pam_filter.so
-rwxr-xr-x  1 root root   7864 May 19 20:33 pam_ftp.so
-rwxr-xr-x  1 root root  15640 May 19 20:33 pam_group.so
-rwxr-xr-x  1 root root   9408 May 19 20:33 pam_issue.so
-rwxr-xr-x  1 root root  11568 May 19 20:33 pam_lastlog.so
-rwxr-xr-x  1 root root  20840 May 19 20:33 pam_limits.so
-rwxr-xr-x  1 root root  18432 May 19 20:33 pam_listfile.so
-rwxr-xr-x  1 root root  10984 May 19 20:33 pam_localuser.so
-rwxr-xr-x  1 root root  12472 May 19 20:33 pam_mail.so
-rwxr-xr-x  1 root root  20216 May 19 20:33 pam_mkhomedir.so
-rwxr-xr-x  1 root root   5856 May 19 20:33 pam_motd.so
-rwxr-xr-x  1 root root   8712 May 19 20:33 pam_nologin.so
-rwxr-xr-x  1 root root   5368 May 19 20:33 pam_permit.so
-rwxr-xr-x  1 root root   8152 May 19 20:33 pam_postgresok.so
-rwxr-xr-x  1 root root  15512 May 19 20:33 pam_rhosts_auth.so
-rwxr-xr-x  1 root root   5560 May 19 20:33 pam_rootok.so
-rwxr-xr-x  1 root root   6840 May 19 20:33 pam_rps.so
-rwxr-xr-x  1 root root  10328 May 19 20:33 pam_securetty.so
-rwxr-xr-x  1 root root   9080 May 19 20:33 pam_shells.so
-rwxr-xr-x  1 root root 810416 Jan 15 15:35 pam_smbpass.so
-rwxr-xr-x  1 root root  12456 May 19 20:33 pam_stack.so
-rwxr-xr-x  1 root root  12624 May 19 20:33 pam_stress.so
-rwxr-xr-x  1 root root  19768 May 19 20:33 pam_succeed_if.so
-rwxr-xr-x  1 root root  17152 May 19 20:33 pam_tally.so
-rwxr-xr-x  1 root root  11488 May 19 20:33 pam_time.so
-rwxr-xr-x  1 root root  19816 May 19 20:33 pam_timestamp.so
-rwxr-xr-x  1 root root  51096 May 19 20:33 pam_unix.so
lrwxrwxrwx  1 root root     11 May 19 20:33 pam_unix_acct.so -> pam_unix.so
lrwxrwxrwx  1 root root     11 May 19 20:33 pam_unix_auth.so -> pam_unix.so
lrwxrwxrwx  1 root root     11 May 19 20:33 pam_unix_passwd.so -> pam_unix.so
lrwxrwxrwx  1 root root     11 May 19 20:33 pam_unix_session.so -> pam_unix.so
-rwxr-xr-x  1 root root 737664 May 19 20:33 pam_userdb.so
-rwxr-xr-x  1 root root   6800 May 19 20:33 pam_warn.so
-rwxr-xr-x  1 root root  15576 May 19 20:33 pam_wheel.so
-rwxr-xr-x  1 root root  18400 May 19 20:33 pam_xauth.so

Recompilen (emergen) van shadow (waar su in zit), pam en pam-login heb ik al meerdere keren geprobeerd...

Maker van Taekwindow; verplaats en resize je vensters met de Alt-toets!

dinsdag 31 mei 2005 22:51

Acties:

WildernessChild

Voor al uw hersenspinsels

Topicstarter

Okee, ik heb compleet bij toeval het probleem ontdekt, toen ik bij iets heel anders toevallig "which su" intikte. Die bleek in ~/usr/bin te staan...

Evengoed bedankt voor al jullie hulp!

Maker van Taekwindow; verplaats en resize je vensters met de Alt-toets!

woensdag 1 juni 2005 10:34

Acties:

xzenor

Ja doe maar. 1 klontje suiker.

Stomme fout, maar een foutje is menselijk...
Blijkbaar heb je dus ook of je homedir in je path staan of je current dir ( . dus).
Is op zich niet erg maar zet die niet voorin je path maar achterin, om voortaan dit soort dingen te voorkomen. Het path wordt namelijk van voor naar achter bekeken.

Als je current dir eerder bekeken wordt dan de rest van je path is dat zelfs een behoorlijk security risico als er meerdere mensen shell access hebben.

Als ik het voor mekaar krijg om ergens een mooie aangepaste niet zo vriendelijke versie van het commando ls neer te zetten in een directory en jij komt in die dir en doet daar ls dan ben je dus de l*l.
Dan wordt mijn versie van ls uitgevoerd en niet de echte, en je kan zelf de gevolgen wel bedenken lijkt me...