silent login/gdm failures and sudo segfaults with smbpasswd enabled

Were there any errors in /var/log/auth.log in connection with these login failures?

yes, the error in auth.log was:
login[5726]: pam_unix(login:auth): authentication failure loginname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=root

This is an error message from a console login (i.e., on tty1), not a GNOME login. Are there no other PAM error messages in the log?

The config you quoted is a fairly standard one, which hasn't caused login failures here - so I'm not sure how to debug this if there were no log messages.

I also got this error in the log:
gdm[5829] pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=0: ruser=rhost = user=my_username

I'm not very familar with this topic, therefore I don't know if this information has anything to do with the topic, maybe it helps:
- I'm using Ubuntu 64 Bit
- I think since I changed the config, firefox (npviewer.bin more precisely) crashes/lockes on flash videos (i.e. youtube)

Unfortunately that error shows only that pam_unix believes you failed to login correctly (i.e., that the password typed was wrong); enabling or disabling pam_smbpass would have no bearing on this.

I suppose it could have an effect on gdm's behavior /after/ a failed login, but that doesn't seem to be the problem you're reporting?

Are there no other PAM log messages at all from the time in question? Note that by this point, the auth.log has probably been rotated, so that the relevant log has now moved to /var/log/auth.log.1.gz or similar.

In the attachment there are parts of the auth.log from the time in question, I left out duplicate parts. My editing in the config to fix the problem could be the reason for errors at the end of the log.

I also tried to reproduce the bug, by setting auth-common and auth-password back to the "old" version from my first post. In a second terminal, I tried to do a 'sudo -s' and got this in Terminal: Segmentation fault.

Unfortunately this doesn't seems to be the same problem to me, since the behaviour is different (didn't get any error in terminal in the first place).
But anyway, here is the entry in auth.log corresponding to the new login try:
Nov 16 22:40:01 my-username-desktop CRON[19449]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 16 22:40:01 my-username-desktop CRON[19449]: pam_unix(cron:session): session closed for user root

>I suppose it could have an effect on gdm's behavior /after/ a failed login, but that doesn't seem to be the problem you're reporting?
No, I don't think so. Maybe I mistyped at my first login try, but I also restarted and still couldn't log in.

  Nov 2 18:48:53 my_username-desktop gdm[5928]: pam_nologin(gdm:auth): cannot determine username

This error in particular suggests a problem unrelated to the contents of /etc/pam.d/common-auth. The standard contents of /etc/pam.d/gdm are:

auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth optional pam_gnome_keyring.so

That means pam_nologin.so is failing to recover the username, and the authentication stack short-circuits at that point, before we ever look at anything in /etc/pam.d/common-auth. So whatever this problem is, it appears to be unrelated to pam_smbpass or any other contents of /etc/pam.d/common-auth.

  Nov 2 18:55:59 my_username-desktop gdm[5829]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=my_username

This next error is the one cited before, and points to a simple login failure.

  Nov 2 20:45:40 my_username-desktop login[5708]: PAM bad jump in stack

This, as you mentioned, could be a result of trying to edit the config.

And these lines:

  Nov 16 22:40:01 my-username-desktop CRON[19449]: pam_unix(cron:session): session opened for user root by (uid=0)
  Nov 16 22:40:01 my-username-desktop CRON[19449]: pam_unix(cron:session): session closed for user root

correspond to periodic cron sessions, not anything related to your logins.

> I also tried to reproduce the bug, by setting auth-common and auth-password back to the "old"
> version from my first post. In a second terminal, I tried to do a 'sudo -s' and got this in Terminal:
> Segmentation fault.

This is probably the most promising avenue of investigation. Do you get any log messages in /var/log/auth.log that match up with this segfault? If not, can you reproduce it when running 'sudo -s' from a root shell? (This would let us get a backtrace from sudo using gdb)

I just ran into this (horrible) problem today!
I haven't tried the proposed solution yet, but for the moment I want to detail how it came up in my experience.

- The system was up & running smoothly.
- I tried to add a printer though the CUPS web administration interface.
- When about to commit the modifications, CUPS asked for user and password. Username was already set to "root".
- I put my own password (not root's one), which CUPS refused.
- I went on typing the wrong password three times.
- I realized that maybe I should use my own login name, so i tried with my login and password.
- After that CUPS server crashed (didn't respond anymore)
- I tried to "sudo bash" in order to restart it
- sudo refused my password
- From then on, any attempt to log in with my username was refused, in the same way described in the original post
- Any attempt to use passwd to reset the password give "segmentation fault", either from root or from my user account.

Now I'm going to try editing the pam config files.

Please fix this bug. It's REALLY a pain!
-Luca

Yes! It worked out!

Many, many, many thanks to Solberg for taking its time to describe the problem and the solution he found!

No problem :)

>Do you get any log messages in /var/log/auth.log that match up with this segfault?
No, nothing in auth.log

> If not, can you reproduce it when running 'sudo -s' from a root shell? (This would let us get a backtrace from sudo using gdb)

I'm not sure if I've got you right, here is what I did:
- Open terminal -> sudo -s -> got a root shell
- Change common-auth and common-password back to the "old" version
- went back to the root shell and typed 'sudo -s'

Here is what I got in the root shell:
root@my_username_desktop:~# sudo -s
root@my_username-desktop:~#

This is the corresponding entry in auth.log
Nov 19 18:31:09 my_username-desktop sudo: root : TTY=pts/0 ; PWD=/home/my_username ; USER=root ; COMMAND=/bin/bash

I have something more to add:

while Soldberg's solution allows me to log in, if in Gnome I lock the session, I'm stuck: I'm not able to get back to my session

@ Luca A

Sounds exactly like the issue I have been having after playing with Cups and Samba. I managed to print out the dmesg if its of any use. Right now I cannot login remotely or at the console, everything seg faults.

[74541.075306] type=1503 audit(1227149670.372:6): operation="inode_permission" requested_mask="rw::" denied_mask="rw::" fsuid=0 name="/var/lib/samba/group_mapping.ldb" pid=4536 profile="/usr/sbin/cupsd"
[74541.080080] type=1503 audit(1227149670.382:7): operation="inode_permission" requested_mask="rw::" denied_mask="rw::" fsuid=0 name="/var/lib/samba/group_mapping.ldb" pid=4536 profile="/usr/sbin/cupsd"
[74550.926825] type=1503 audit(1227149680.222:8): operation="inode_permission" requested_mask="rw::" denied_mask="rw::" fsuid=0 name="/var/lib/samba/group_mapping.ldb" pid=4536 profile="/usr/sbin/cupsd"
[74550.939972] type=1503 audit(1227149680.232:9): operation="inode_permission" requested_mask="rw::" denied_mask="rw::" fsuid=0 name="/var/lib/samba/group_mapping.ldb" pid=4536 profile="/usr/sbin/cupsd"
[74553.537775] type=1503 audit(1227149682.840:10): operation="inode_permission" requested_mask="x::" denied_mask="x::" fsuid=0 name="/usr/share/samba/panic-action" pid=9854 profile="/usr/sbin/cupsd"
[74553.572975] cupsd[4536]: segfault at 0 ip b7079abb sp bff6c5a0 error 4 in pam_smbpass.so[b701d000+12a000]
[74748.747900] sshd[10231]: segfault at 0 ip b7889abb sp bffe64f0 error 4 in pam_smbpass.so[b782d000+12a000]
[74766.293556] sshd[10317]: segfault at 0 ip b77deabb sp bfc3b150 error 4 in pam_smbpass.so[b7782000+12a000]
[74811.520132] sshd[10361]: segfault at 0 ip b7868abb sp bfec6bd0 error 4 in pam_smbpass.so[b780c000+12a000]
[74828.318587] login[26776]: segfault at 0 ip b7c58abb sp bfe58770 error 4 in pam_smbpass.so[b7bfc000+12a000]
[74847.315675] login[10455]: segfault at 0 ip b7cc8abb sp bfcc6de0 error 4 in pam_smbpass.so[b7c6c000+12a000]
[74864.392785] login[10479]: segfault at 0 ip b7c5eabb sp bfa5eb80 error 4 in pam_smbpass.so[b7c02000+12a000]
[75102.607384] sudo[11095]: segfault at 0 ip b7d72abb sp bf9816d0 error 4 in pam_smbpass.so[b7d16000+12a000]
[75140.509963] sudo[11204]: segfault at 0 ip b7c0fabb sp bfc20170 error 4 in pam_smbpass.so[b7bb3000+12a000]
[75166.670099] sudo[11233]: segfault at 0 ip b7d05abb sp bf815d60 error 4 in pam_smbpass.so[b7ca9000+12a000]
[75203.610623] sudo[11348]: segfault at 0 ip b7d47abb sp bfa567a0 error 4 in pam_smbpass.so[b7ceb000+12a000]
[75298.191437] sudo[11599]: segfault at 0 ip b7dcfabb sp bfde0b40 error 4 in pam_smbpass.so[b7d73000+12a000]
[75309.912374] sudo[11614]: segfault at 0 ip b7c3aabb sp bf84ada0 error 4 in pam_smbpass.so[b7bde000+12a000]
[75315.274615] sudo[11622]: segfault at 0 ip b7db7abb sp bf9c7f30 error 4 in pam_smbpass.so[b7d5b000+12a000]
[75348.251185] sudo[11656]: segfault at 0 ip b7cfcabb sp bfa0cf70 error 4 in pam_smbpass.so[b7ca0000+12a000]

> [74541.075306] type=1503 audit(1227149670.372:6): operation="inode_permission" requested_mask="rw::" denied_mask="rw::" fsuid=0 name="/var/lib/samba/group_mapping.ldb" pid=4536 profile="/usr/sbin/cupsd"

This bug was reported against Ubuntu 8.10. Segfaults in cupsd due to both pam_smbpass and apparmor being enabled are a known bug in the version of apparmor that shipped in Ubuntu 8.04 - but this was resolved in an update almost immediately after the 8.04 release.

If you do not already have the hardy-updates repository enabled in System -> Administration -> Software Sources, you should.

That bug was never present in Ubuntu 8.10 and is unrelated to this bug report.

I noticed that my samba daemon is not running anymore:

 /etc/init.d/samba restart
 * Stopping Samba daemons
                   start-stop-daemon: warning: failed to kill 5093: No
such process

            [ OK ]
 * Starting Samba daemons
            [ OK ]

/var/log/samba# cat log.smbd
[2008/11/23 16:34:52, 0] smbd/server.c:main(1213)
  smbd version 3.2.3 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2008
[2008/11/23 16:34:52, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:34:52, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:34:52, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:34:52, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:34:52, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1650750572 len=24
[2008/11/23 16:34:52, 0] passdb/machine_sid.c:pdb_generate_sam_sid(166)
  pdb_generate_sam_sid: Failed to store generated machine SID.
[2008/11/23 16:34:52, 0] lib/util.c:smb_panic(1663)
  PANIC (pid 10211): could not generate a machine SID
[2008/11/23 16:34:52, 0] lib/util.c:log_stack_trace(1767)
  BACKTRACE: 6 stack frames:
   #0 /usr/sbin/smbd(log_stack_trace+0x2d) [0xb7cc23cc]
   #1 /usr/sbin/smbd(smb_panic+0x80) [0xb7cc2529]
   #2 /usr/sbin/smbd(get_global_sam_sid+0x6f3) [0xb7bc9247]
   #3 /usr/sbin/smbd(main+0x9f7) [0xb7b62530]
   #4 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7683685]
   #5 /usr/sbin/smbd [0xb7b5faf1]
[2008/11/23 16:34:52, 0] lib/util.c:smb_panic(1668)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 10211]
[2008/11/23 16:34:52, 0] lib/util.c:smb_panic(1676)
  smb_panic(): action returned status 0
[2008/11/23 16:34:52, 0] lib/fault.c:dump_core(201)
  dumping core in /var/log/samba/cores/smbd

#/etc/init.d/samba status
 * nmbd is running.
 * smbd is not running.

This is after Solbergs modifications.
if I reset the orginal files, i get this:

[2008/11/23 16:43:13, 0] smbd/server.c:main(1213)
  smbd version 3.2.3 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2008
[2008/11/23 16:43:13, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:43:13, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:43:13, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:43:13, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1886330996 len=24
[2008/11/23 16:43:13, 0] lib/util_tdb.c:tdb_wrap_log(886)
  tdb(/var/lib/samba/secrets.tdb): transaction_read: failed at
off=1650750572 len=24
[2008/11/23 16:43:13, 0] passdb/machine_sid.c:pdb_generate_sam_sid(166)
  ...

Soldberg,

Ok, sounds like we unfortunately can't debug the segfault that way.

You mentioned that you got this behavior by setting the PAM config back to its "old" version, but you commented on the old config versions you posted that you weren't "100% sure" about their contents. Can you please confirm the exact contents of /etc/pam.d/common-auth and /etc/pam.d/common-account when you're seeing this segfault, so I can try to reproduce it here?

The config that you copied in the bug report had several typos that would be fatal config errors, so I haven't tried using it as a basis for reproducing this bug.

I justed reproduced the segmentation fault, using the config files in the attachment.
Using these attached config's, I get the seg fault when trying 'sudo -s' from a normal (non-root) shell.

and here is the common-password

Soldberg,

This is not reproducible for me with the common-auth provided. I specifically need the common-account that accompanies this - not common-password, which has nothing to do with logins except in the case of accounts with expired passwords.

Hi,

here is the common-account.
I just reproduced the seg fault when trying 'sudo -s' again. I used the common-auth I already postet as attachment and the common-account attached to this post.

My dears friends... I got the same Issue!!! yesterday!!!

I installed Samba, because I was wanting to share one folder with virtual box then, When I restart... I wasn't able to login...

I try with...

/etc/pam.d/common-auth
-----------------------------------------------------------------------------------------------------------------------------------------------------
auth [success=1 default=ignore] pam_unix.so nullok_secure
#Btw I comment the following line, because I wasn't able to resolve...
#auth sufficient /lib/security/pam_lsass.so try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
#auth optional pam_smbpass.so migrate
# end of pam-auth-update config

my /etc/pam.d/common-password
------------------------------------------------------------------------------------------------------------------------------------------------------
password [success=1 default=ignore] pam_unix.so obscure sha512
#Btw I comment the following line, because I wasn't able to resolve...
#password sufficient /lib/security/pam_lsass.so try_first_pass use_authtok
password requisite pam_deny.so
password required pam_permit.so
#password optional pam_smbpass.so nullok use_authtok use_first_pass

Right now I am able to login with my cute account...
First starting the dbus, then reconfiguring the hal... and finally startx...
that is my only way to login using, only in the recovery area... T_T and that is pretty sad...

My log is pretty simlar... let me show you an example of the last 5 hours.. ^.^
-------------------------------------------------------------------------------------------------------------------------------------------------------
Dec 4 00:08:04 nayuki gdm[5060]: pam_nologin(gdm:auth): cannot determine username
Dec 4 00:16:27 nayuki gdm[5041]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=darksaber
Dec 4 00:16:55 nayuki login[4218]: FAILED LOGIN (1) on 'tty2' FOR `root', Authentication failure
Dec 4 00:21:38 nayuki login[5396]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=root
Dec 4 00:21:38 nayuki login[5396]: [module:pam_lsass]pam_sm_authenticate error [login:root][error code:32784]
Dec 4 00:21:40 nayuki login[5396]: FAILED LOGIN (1) on 'tty2' FOR `root', Authentication failure
Dec 4 00:21:50 nayuki gdm[5041]: pam_nologin(gdm:auth): cannot determine username
Dec 4 05:08:22 nayuki gdm[5090]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=darksaber
Dec 4 05:08:48 nayuki gdm[5090]: pam_nologin(gdm:auth): cannot determine username
Dec 4 05:25:07 nayuki gdm[5065]: PAM unable to dlopen(/lib/security/pam_lsass.so): /lib/security/pam_lsass.so: no se puede abrír el archivo de objeto compartido: No existe el fichero ó directorio
Dec 4 05:25:07 nayuki gdm[5065]: PAM adding faulty module: /lib/security/pam_lsass.so
Dec 4 05:25:12 nayuki gdm[5065]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=darksaber
Dec 4 05:25:15 nayuki gdm[5065]: PAM unable to dlopen(/lib/security/pam_lsass.so): /lib/security/pam_lsas...

mmm...

If I try to login yo my account I got this

root@nayuki:~# su - darksaber
su: Authentication failure
(Ignored)
darksaber@nayuki:~$

I was able to change password to my user. But I wasn't able to login with that password... ^.^

Soldberg,

I've tested here with both the common-auth and common-account that you've provided, and I'm afraid I still can't reproduce the segfault or the login failures. I've even tried mangling the databases under /var/lib/samba/ to confuse pam_smbpass into segfaulting, and everything works correctly here. I'm afraid there's nothing more I can do here unless someone figures out a way to get a backtrace from your crash.

Perhaps the best bet is to turn apport on, via /etc/default/apport.

On Thu, Dec 04, 2008 at 02:41:42PM -0000, ariel.darkserver wrote:
> My dears friends... I got the same Issue!!! yesterday!!!

This is not the same issue. It's not even remotely related.

> /etc/pam.d/common-auth
> -----------------------------------------------------------------------------------------------------------------------------------------------------
> auth [success=1 default=ignore] pam_unix.so nullok_secure
> #Btw I comment the following line, because I wasn't able to resolve...
> #auth sufficient /lib/security/pam_lsass.so try_first_pass

I don't know what this is, but it's not part of Samba - it's not included in
Samba upstream, nor is it part of the Ubuntu Samba packages, or part of any
package in Ubuntu.

A google search for this module name suggests that it may be part of the
commercial version of Likewise. I suggest you contact your vendor for help
with this; I believe they're familiar with the issue, since the same problem
showed up during development of Ubuntu 8.10 using the likewise-open packages
included in Ubuntu, and was resolved.

If this isn't Likewise, then I really have no idea what it is - but in any
event you'll need to go back to whoever provided your version of Samba, this
isn't something we can provide support for here.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

ok, thanks for trying anyway!

Soldberg, ariel.darkserver
are you having the same problem as I have? I mean I cannot use anymore the "lock session" functionality, in gnome. If I do, I cannot log back in, it refuses my password.

Luca A,
since I have changed the common-auth and common-password, I don't have any login problems. lock session in gnome and login in again works fine.

Luca A (and all).

I had the same original problem of the looping login / segfaults and then samba problems (post 14 here). I had followed all the suggestions here and ran into the same issue that Luca A has.

After some help from jrib and marcelkoopman on #ubuntu (irc.freenode.net) I got everything working again.

Essentially all I did was revert common-auth and common-password to their original states - ie including the problematic lines, completely remove samba and samba-common (including all the dependancies of samba-common) using synaptic, reboot my machine, reinstall the two packages and hey presto its all working again :)

Many thanks to jrib and marcelkoopman for their help.

Ohkie

I confirm this problem. For about two weeks I was unable to login. I don't know if I did any changes to the system.

- Local login always displayed the login-promt again
- ssh closed connection
- authentication for root-permissions within gdm was not possible, it reacted as if the cancel-button of the authentication dialogue was pressed when trying to install updates.

After removing samba and samba-common with --purge it worked again.
I backed up my /etc/samba/smb.conf before.

Thnak you guys for your info.
When I try to "mark for complete removal" samba-common from synaptics, it tell me that it will remove also ubuntu-desktop (amongh others packages). Is it safe to continue?

I went on removing all the mentioned packages and the reinstall.
I'm still having the problem with "lock session" in gnome. However login works properly with the common-auth and common-password set to their original states.

Yes it's safe to remove ubuntu-desktop but it's better to reinstall to avoid errors with upgrading.

I've encountered the same problem twice already. If the user that can't login due to the problem is the admin account, how can I edit the common-auto and common-password files?

To mangwills:

you have to reboot, choose "safe mode". You get into a text-mode menu. Choose "open root session" (or similar. I can't remember exactly). From there you can modify the files. You must use a terminal-based editor like vi, nano or emacs. I suggest to use nano, it's the simplest one. When done, type "exit" at the prompt to get back to the menu.

Thanks! That worked out well. I also removed samba and samba-client, then
reinstalled them, and everything worked well again.

2008/12/25 Luca A <email address hidden>

> To mangwills:
>
> you have to reboot, choose "safe mode". You get into a text-mode menu.
> Choose "open root session" (or similar. I can't remember exactly). From
> there you can modify the files. You must use a terminal-based editor
> like vi, nano or emacs. I suggest to use nano, it's the simplest one.
> When done, type "exit" at the prompt to get back to the menu.
>
> --
> silent login/gdm failures and sudo segfaults with smbpasswd enabled
> https://bugs.launchpad.net/bugs/292791
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "pam" source package in Ubuntu: New
>
> Bug description:
> Ubuntu 8.10
>
> Had no problems with Intrepid at first, but then login wasn't possible
> anymore. After entering username and password in the gnome login-gui,
> nothing happend and I got the username prompt again. Same problem in the
> terminal. After entering username and password, I got again the login
> prompt. There was no message like 'login incorrect', just the prompt again.
>
> I solved the problem by editing the files /etc/pam.d/common-auth and
> /etc/pam.d/common-password:
>
> Old /etc/pam.d/common-auth (I'm not 100% sure about this):
> auth [succes=1 default=ignore] pam_unix.so nullok_secure
> auth requisite pam_dey.so
> auth required pam_permit.so
> auth optional pam_smbpass.so migrate
>
> New /etc/pam.d/common-auth:
> auth [succes=1 default=ignore] pam_unix.so nullok_secure
> auth requisite pam_dey.so
> auth required pam_permit.so
> #auth optional pam_smbpass.so migrate
>
> Old /etc/pam.d/common-password (again, not 100% sure about that):
> password [success=1 default=ignore] pam_uni.so obscure sha512
> password requisite pam_deny.so
> password required pam_permit.so
> password optional pam_smbpass.so nullok use_authtok use_first_pass
>
>
> New /etc/pam.d/common-password:
> password [success=1 default=ignore] pam_uni.so obscure sha512
> password requisite pam_deny.so
> password required pam_permit.so
> #password optional pam_smbpass.so nullok use_authtok use_first_pass
>

I would like to add, I also experienced this bug today. Everything was working nicely and I tried to change the halftoning setting for my printer via the CUPS HTTP admin interface. CUPS crashed, and I was unable to access any samba shares. When I attempted to login via SSH, I got prompted for my username and password, and then putty complained that the connection was closed unexpectedly by the server.

Logging in locally would not work either, it was stuck in a loop like this:
------------------------
Ubuntu 8.10 hinata tty1
hinata login: <entered username>
password: <entered password>

Ubuntu 8.10 hinata tty1
hinata login: <-- back here again, no errors
------------------------

No errors in log files or anything. Thank you very much to those that have posted comments alongside this bug report, with your help I was able to get my system working again. I rebooted and hit ESC to get a GRUB menu, chose recovery mode and root console. I then entered:

cp /etc/samba/smb.conf ~
apt-get autoremove cups --purge
apt-get autoremove samba --purge
apt-get autoremove samba-common --purge
shutdown -r now

I was able to login upon reboot and then reinstall samba and copy my config file back. I had to readd my password using smbpasswd but it's working. Am I brave enough to try CUPS yet....?

Sorry I should add that I'm using ubuntu server 8.10 and have not installed any exotic/non standard packages.

On more thing on the residual problem I had with session unlock: I found the solution. It's another bug:

https://bugs.launchpad.net/bugs/279560

I can confirm that I have the same "unable to log in" issue with Intrepid 8.10.
First, a little history ...
Several months ago I burned an ISO of Hardy Heron 8.04.
Two weeks ago I finally got around to trying it and decided to install it.
I installed the recommended upgrades and used it for a day or so before I went for the Intrepid Ibex 8.10 Upgrade network install from the Ubuntu web site.
Wanting Flash I plugged it in to FireFox. After a few days, whenever I accessed a site that featured a Flash enabled program, FireFox stopped responding and had to be closed down.
Meanwhile, wanting to set up a two PC router based wired home network I install Samba and promptly entered into configuration Hell, the details of which are posted here:

http://ubuntuforums.org/showthread.php?t=1025748

I eventually got Samba running and had my shares fully accessible to the network. Shortly thereafter I enters a new level of Hell ... Segmentation Faults mostly around Samba.
A little research suggested that Segmentation Faults were probably associated with bad memory or an installation becoming corrupted.
I shut down my PC and started checking my RAM sticks ... I found and replaced/removed two bad ones.
Ever since then, I am unable to log in to Intrepid. Going into the command line via Grub does not work either.

I hauled out my Hardy ISO and reinstalled it on a separate partition and now have a dual boot 8.04/8.10 system, but Intrepid is still inaccessible, however, via Hardy, as expected, I am able to see my Intrepid drive.

Ok ... here is the opportunity. [DISCLAIMER: I am a virtual Linux noobe] I am comfortable with going in and tweaking things and I can work with the Terminal and command lines. Tell me what you need to look at and where I can find it and I will deliver it. I will not attempt to fix my Intrepid until you have all that you need and are able to offer a bugfix.

Michael, did you have the libpam-smbpass package installed previously? This failure is still not reproducible for me here; are you in a position to reinstall libpam-smbpass to see if the problem reappears for you?

Walter, do you have libpam-smbpass installed on your inaccessible intrepid install?

When I had the same problem before, libpam-smbpass was installed. Removing
samba completely removed that package. Libpam-smbpass was installed when I
shared a folder (which prompted me to have samba installed automatically).
The problem started when I tried stopping a shared printer with ongoing
print jobs in the CUPS web administration page.

William

2009/1/5 Steve Langasek <email address hidden>

> Michael, did you have the libpam-smbpass package installed previously?
> This failure is still not reproducible for me here; are you in a
> position to reinstall libpam-smbpass to see if the problem reappears for
> you?
>
> Walter, do you have libpam-smbpass installed on your inaccessible
> intrepid install?
>
> --
> silent login/gdm failures and sudo segfaults with smbpasswd enabled
> https://bugs.launchpad.net/bugs/292791
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "pam" source package in Ubuntu: New
>
> Bug description:
> Ubuntu 8.10
>
> Had no problems with Intrepid at first, but then login wasn't possible
> anymore. After entering username and password in the gnome login-gui,
> nothing happend and I got the username prompt again. Same problem in the
> terminal. After entering username and password, I got again the login
> prompt. There was no message like 'login incorrect', just the prompt again.
>
> I solved the problem by editing the files /etc/pam.d/common-auth and
> /etc/pam.d/common-password:
>
> Old /etc/pam.d/common-auth (I'm not 100% sure about this):
> auth [succes=1 default=ignore] pam_unix.so nullok_secure
> auth requisite pam_dey.so
> auth required pam_permit.so
> auth optional pam_smbpass.so migrate
>
> New /etc/pam.d/common-auth:
> auth [succes=1 default=ignore] pam_unix.so nullok_secure
> auth requisite pam_dey.so
> auth required pam_permit.so
> #auth optional pam_smbpass.so migrate
>
> Old /etc/pam.d/common-password (again, not 100% sure about that):
> password [success=1 default=ignore] pam_uni.so obscure sha512
> password requisite pam_deny.so
> password required pam_permit.so
> password optional pam_smbpass.so nullok use_authtok use_first_pass
>
>
> New /etc/pam.d/common-password:
> password [success=1 default=ignore] pam_uni.so obscure sha512
> password requisite pam_deny.so
> password required pam_permit.so
> #password optional pam_smbpass.so nullok use_authtok use_first_pass
>

Steve, I have the following files and locations on my 8.10 inaccessible drive:

/media/disk/etc/logcheck/ignore.d.server/libpam-smbpass
/media/disk/var/lib/dpkg/info/libpam-smbpass.conffiles
/media/disk/var/lib/dpkg/info/libpam-smbpass.list
/media/disk/var/lib/dpkg/info/libpam-smbpass.md5sums
/media/disk/var/lib/dpkg/info/libpam-smbpass.postinst
/media/disk/var/lib/dpkg/info/libpam-smbpass.prerm
/media/disk/var/cache/apt/archives/libpam-smbpass_2%3a3.2.3-1ubuntu3.3_i386.deb

PS: Was it you that shut down my furnace so that the cold would wake me up to find your reply? rofl

Hmm ... just found out that these comments can't be edited in any obvious way ...

I also found the following folder:
/media/disk/usr/share/doc/libpam-smbpass/
which contains a readme, a to-do, a copyright, several .gz files and an examples folder.

There are no libpam-smbpass files on the Hardy partition.

Steve it seems I did have libpam-smbpass installed. Will it be sufficient for me to apt-get install that package again and try to reproduce or do I need to configure in some particular way?

Michael, yes, apt-get install libpam-smbpass should be enough to try to reproduce the problem again, and apt-get remove libpam-smbpass should be sufficient to restore your 8.10 system to working order so you can make productive use of it in between debugging sessions.

Walter,

This recipe should permit reproducing the crashes from your intrepid system; if you can confirm this to be the case, we can go from there on trying to get debugging information out of it.

$ sudo chroot /media/disk su <username>
$ sudo -s

where <username> is the name of your admin user on the Ubuntu 8.10 install.

That will let us see if sudo is crashing within the 8.10 installation.

Hi Steve,

Note that there is an icon on my desktop for "9.6 GB Media". It also shows under Places>Computer.
It is my /media/disk folder.

I opened terminal and got this:

web@2kbox:~$ sudo chroot /media/disk su web
[sudo] password for web:
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
===== this line repeated about 100 times =====
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
web@2kbox:/$

I did not try to run sudo -s.

I rebooted my system and tried again.
This time I got:

web@2kbox:~$ sudo chroot /media/disk su web
[sudo] password for web:
chroot: cannot change root directory to /media/disk: No such file or directory
web@2kbox:~$

The 9.6 GB Media icon was gone from my desktop. I assume this was because that drive did not mount with the reboot. I accessed it via Places>Computer which caused the icon to reappear. I then ran

web@2kbox:~$ sudo chroot /media/disk su web
[sudo] password for web:

and once again got:
bash: /dev/null: Permission denied
web@2kbox:/$

This time I ran and got:
web@2kbox:/$ sudo -s
sudo: must be setuid root
web@2kbox:/$

Steve,

I did a little thinking and some poking about on my 8.10 partition.
I looked at auth.log and noticed several of the following:

Jan 2 20:32:37 2kbox gdm[5340]: pam_unix(gdm:auth): auth could not identify password for [WEB]

WEB is my 98box user name. The 2kbox (8.10) should be web (lower case). I checked the auth.log on my 8.04 partition and there it is web as expected.

My thoughts on what may be my problem:
1. The SEGMENTATION FAULT error properly identified the fact that I had some bad RAM.
2. Since replacing the bad RAM, I no longer see the SEGMENTATION FAULT error.
3. Part of the login process writes data into RAM (Is this correct?) and the data was written into the faulty RAM addresses (Is this possible?)
4. Note that the SEG FAULT issue did not appear until I had Samba properly configured and could see my shares on both PCs in the network.
5. Would the login process write data to RAM, then change a state in a file on the disk, which upon logout or timeout, would be restored to the original state as stored in RAM?
6. The assumption here is that the data written to RAM was corrupted or lost due to being written to the bad RAM.
7. The hosts file on the 2kbox resolves web = WEB for my 98box access to Samba.

Does any of this make sense?

I've attached the 8.10 auth.log file.

Steve,

I ran into the same issue just yesterday. sudo started segfaulting right after installing a few samba-related packages. I've been able to make a backtrace (see attachment).

Commenting out the line with pam_smbpass.so in /etc/pam.d/common-auth has fixed the problem for me.

Jorrit,

On Tue, Jan 20, 2009 at 09:23:48PM -0000, Jorrit Kronjee wrote:
> I ran into the same issue just yesterday. sudo started segfaulting right
> after installing a few samba-related packages. I've been able to make a
> backtrace (see attachment).

Thanks very much! I don't know why the backtrace shows what it does given
that I thought the bugs related to this had all been fixed already, but it
gives me enough information to track it down and put this issue to rest.

Can you tell me what version of libpam-smbpass you have installed? (dpkg -l
libpam-smbpass)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve:
It looks related to bug 303458 (and his evil duplicate bug 302092)
The problem we solved was bug 260687 (libpam-smbpass segfault caused by missing /var/lib/samba), but there seem to be a case of /var/lib/samba/ contents corruption triggering a similar segfault.

On Wed, Jan 21, 2009 at 01:18:53PM -0000, Thierry Carrez wrote:

> It looks related to bug 303458 (and his evil duplicate bug 302092)
> The problem we solved was bug 260687 (libpam-smbpass segfault caused by
> missing /var/lib/samba), but there seem to be a case of /var/lib/samba/
> contents corruption triggering a similar segfault.

What's the basis for claiming that there's a corruption problem? I haven't
seen tdb corruption in samba for many years.

The backtrace in this bug isn't a corruption issue at all; the
get_global_sam_sid() call panics if called by a process that can't create or
read /var/lib/samba/secrets.tdb. The trick is that libpam-smbpass isn't
supposed to call get_global_sam_sid() - so something has changed here.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

By corruption I didn't mean a corrupted bits in a specific file, but rather a corrupted state for the global /var/lib/samba directory contents... The basis for this is that in the mentionned bugs clearing the directory (and especially the existing secrets.tdb file) made everything working again. Clearly the backtrace analysis is more precise than this wild guess based on observed symptoms.

Thierry Carrez wrote:
> By corruption I didn't mean a corrupted bits in a specific file, but
> rather a corrupted state for the global /var/lib/samba directory
> contents... The basis for this is that in the mentionned bugs clearing
> the directory (and especially the existing secrets.tdb file) made
> everything working again. Clearly the backtrace analysis is more precise
> than this wild guess based on observed symptoms.
>
>
Steve, Thierry,

root@hercules:~# mv /var/lib/samba/ /var/lib/samba.bak/
root@hercules:~# exit
jorrit@hercules:~$ sudo -s
[sudo] password for jorrit:
Segmentation fault

Also, the version of libpam-smbpass I'm currently using is
2:3.2.3-1ubuntu3.4

Let me know if there's more information you need.

Jorrit: it will indeed segfault if there is no /var/lib/samba directory anymore. But an existing (empty) /var/lib/samba should work (files will be recreated). That is, if this bug is the same as the other two I mentionned.

Thierry Carrez wrote:
> Jorrit: it will indeed segfault if there is no /var/lib/samba directory
> anymore. But an existing (empty) /var/lib/samba should work (files will
> be recreated). That is, if this bug is the same as the other two I
> mentionned.
>
>
Thierry,

I guess you are right. Creating an empty directory did solve the problem.

The "missing /var/lib/samba dir" bug, bug #260687, is purported to be fixed in version 2:3.2.3-1ubuntu3 - earlier than the version Jorrit reports is installed.

Walter and Martin, can you tell me whether you have a /var/lib/samba directory on your affected systems?

Jorrit, you showed a test involving 'mv /var/lib/samba/ /var/lib/samba.bak/' - did you have a /var/lib/samba directory on your system when the original crash happened that you were reporting?

The pam_smbpass module unfortunately explicitly disables the normal Samba logging, which would have generated a more meaningful error message in a logfile if it were enabled. If we can first confirm that everyone's symptoms are the same, then if everyone can tell me which versions of libpam-smbpass they have installed I can provide a package build that turns on logging for pam_smbpass so we can see what Samba itself /says/ the problem is.

"Walter and Martin, can you tell me whether you have a /var/lib/samba directory on your affected systems?"

Yes ... I do have that directory.

Steve: the fix in bug 260687 is making sure /var/lib/samba is created by moving directory creation to the appropriate package. It's not solving the segfault that happens if it's not there.

However here the problem is different, as it happens with an existing /var/lib/samba directory. Emptying the directory usually solves it, by forcing the re-creation of the files in it.

> the fix in bug 260687 is making sure /var/lib/samba is created by moving directory creation to the appropriate package.
> It's not solving the segfault that happens if it's not there.

Yes, I'm aware.

> However here the problem is different, as it happens with an existing /var/lib/samba directory. Emptying the directory
> usually solves it, by forcing the re-creation of the files in it.

No, that hasn't been shown to be the case; that's why I'm asking the submitters this question, to rule that out.

On 1/22/2009 3:36 AM, Steve Langasek wrote:
> Jorrit, you showed a test involving 'mv /var/lib/samba/
> /var/lib/samba.bak/' - did you have a /var/lib/samba directory on your
> system when the original crash happened that you were reporting?

Steve,

Yes, moving or not moving the directory doesn't make a difference, it
will segfault in both cases. Recreating the directory as Thierry
suggested does fix the problem, though.

Jorrit

Hey All,

Has there been any resolution to this. I had the same problems mentioned in the initial post, changed my 2 pam files, and was able to log back in. However, now my samba server doesn't start and cups still doesn't work properly. I had just installed a fresh Ubuntu 8.10 server 2 days ago when this happened, so it seems this is some kind of bug, no? Is there a way to get samba and cups working well together?

Thanks,
Todd

Hello! At first i've started having segfaults when trying to sudo, then i've restarted my machine and could not login at all. To solve this i've entered recovery mode, opened the root prompt and used this command "apt-get purge -y samba samba-common samba-client libpam-smbpass && apt-get install -y samba libpam-smbpass". The problem its gone, but now i have another error: when i log using gdm, after entering my password, a dialog box appears with the word "Error!" and a "OK" button, and when i click "OK" the system starts just fine. Also, when trying to sudo, i get an "Error", but it still works. Yet also, there is the app System->Administration->Users and Groups which have a error: when trying to unlock it, it locks the window for some seconds, then appears with the dialog box: "Coud not authenticate - An unexpected error has occured" with a Close button. When closing it, the window locks and freezes, and the "Wait or Force Close" dialog appears. Anyone else with these problems?

I'm pretty sure this is avoided in Jaunty through the apparmor fix in bug 357581.
Closing as Fix Released, please reopen if you can reproduce it on Jaunty.
The apparmor patch was nominated for an Intrepid SRU.