Re: Ctrl-M in my system-auth file?

I suggest without the '\r' in the sed line.

$perl -p -e 's/^M//g' < file_with_ctrl-M > file_without_ctrlM

Regards,

[]s Nelson Junior
nelson <at> lunenetworks.com.br
nelson <at> LUNE.com.br

----- Original Message -----
From: "KTSuresh" <kt <at> gwcmail.com>
To: <pam-list <at> redhat.com>
Sent: Friday, June 28, 2002 7:18 PM
Subject: Re: Ctrl-M in my system-auth file?

>
> Most likely u tried some dos editors to edit and save the file. Try this
>
> $perl -p -e 's/^M/\r/g' < file_with_ctrl-M > file_without_ctrlM
>
> 6/28/2002 4:06:52 PM, Alan Womack <arwbackup <at> worldnet.att.net> wrote:
>
> >While continuing work on the ssh problem and putting my pam back
together,
> I ran into this one this morning.
> >
> >Jun 28 07:34:55 Webby login: PAM [dlerror:
/lib/security/pam_nologin.so^M:
> cannot open shared object file: No such file or directory]

re: Ctrl-M in my system-auth file?

Thank you gentleman with the assistance, however there were no ^M control M's in the file even though the
logs were complaining.  I replaced the file for a 5th time with authconfig and all appears to be fine now
except for the ldap issue I just posted.

 >>  I suggest without the '\r' in the sed line.

 >>  $perl -p -e 's/^M//g' < file_with_ctrl-M > file_without_ctrlM

 >>  Regards,

Epson Inkjet Printer FAQ: http://welcome.to/epson-inkjet

User not known to underlying authentication module

pam_ldap is returning this error to the /var/log/secure file if I uncomment the account required
/lib/security/pam_ldap.so line from:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/pam_ldap.so use_first_pass
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so
#account     required      /lib/security/pam_ldap.so

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/pam_ldap.so use_authtok
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
session     optional      /lib/security/pam_ldap.so

I have verified the user is indeed in the ldap database with:

/usr/local/sbin/smbldap-usershow.pl <usernamehere>

there is a full output.

Alan

Re: Ctrl-M in my system-auth file?

Logs don't complain about ^M for nothing. The simplest way to get rid of em is 
to zip it up, then unzip it, for example...

zip -aa temp.zip somefilewithcontrolMs.txt
unzip temp.zip

After that, the ^M's will be gone...

Corey

On Monday 01 July 2002 11:26, Alan Womack wrote:
> Thank you gentleman with the assistance, however there were no ^M control
> M's in the file even though the logs were complaining.  I replaced the file
> for a 5th time with authconfig and all appears to be fine now except for
> the ldap issue I just posted.
>
>  >>  I suggest without the '\r' in the sed line.
>  >>
>  >>  $perl -p -e 's/^M//g' < file_with_ctrl-M > file_without_ctrlM
>  >>
>  >>  Regards,
>
> Epson Inkjet Printer FAQ: http://welcome.to/epson-inkjet
>
>
>
> _______________________________________________
> Pam-list mailing list
> Pam-list <at> redhat.com

Re: md5 passwds not working (suse 7.3) (NOW FIXED)

/me> Anyway, I've just discovered that all apps I've recently compiled
/me> from srpms are failing to auth md5 passwds, but all that were
/me> downloaded as binary rpms are working.

/me> I don't see why that should make a difference, but it is.

I just grabbed and compiled suse 8.0's pam srpms.  Now everything
works again.  (I did not have to recompile the previously broken
packages after installing the updated pam rpms, so it was a runtime
rather than compile-time error.)

I still don't know why stuff I compiled (using rpm) was failing but
stuff from their cds worked, but whatever it was is now corrected.

One bug I found trying to compile pam-0.75-199.src.rpm was due to this
patch in the srpm:

===============================================================================
--- modules/pam_unix/Makefile
+++ modules/pam_unix/Makefile	2002/01/24 17:01:45
 <at>  <at>  -146,7 +146,8  <at>  <at> 
 ifdef DYNAMIC
 	install -m $(SHLIBMODE) $(LIBSHARED) $(FAKEROOT)$(SECUREDIR)
 	for x in pam_unix_auth pam_unix_acct pam_unix_passwd pam_unix_session;\
-		do ln -sf $(LIBSHARED) $(FAKEROOT)$(SECUREDIR)/$$x.so ; done
+		do ln -f $(LIBSHARED) $(FAKEROOT)$(SECUREDIR)/$$x.so ; done
+	rm $(FAKEROOT)$(SECUREDIR)/pam_unix.so
 endif
 	$(MKDIR) $(FAKEROOT)$(SUPLEMENTED)
 	install -m 4555 $(CHKPWD) $(FAKEROOT)$(SUPLEMENTED)

Re: md5 passwds not working (suse 7.3) (NOW FIXED)

[SIGH]  Sorry for the flurry but I thought this info should be added
here for the purpose of the archived.  I suspect what Olaf describes
in the attached message is the same problem I was having with my
compile of cups before I upgraded pam.

In short, it is a -lcrypt vs -lcrypto ordering issue in suse's 7.3 and
earlier pam rpms.

Therefore, adding:

        exdport LD_PRELOAD=/usr/lib/libcrypt.so

to the top of the /etc/init.d/cups file probably would have solved
things for me, rather than having to update pam....

-JimC

From: Olaf Kirch <okir <at> suse.de>
Subject: [suse-security] OpenSSH and MD5 passwords
Date: 2002-06-26 11:36:33 GMT

I investigated this issue and found the problem...

Note that this has nothing to do with the "OpenSSH and PAM

Re: pam_passwdqc, ssh and expired passwords

Hmm - good work Sun.

Looks like I will have to go back to cracklib for want of anything else.
sigh.

John

                                                                                                                   
                    Solar                                                                                          
                    Designer             To:     John Warburton <John.Warburton <at> asic.gov.au>                       
                    <solar <at> openwa        cc:     pam-list <at> redhat.com                                               
                    ll.com>              Fax to:                                                                   
                                         Subject:     Re: pam_passwdqc, ssh and expired passwords                  
                    29/06/2002                                                                                     
                    03:19 AM                                                                                       

***
This email message has been processed by MIMEsweeper
***

Gary Winiger <gww at marduk.eng.sun.com> points out that the following
Solaris 8 bugs all of which are fixed in Solaris 9 are very likely
relevant to this problem:

4284795 when passwd is given the -r option, it ignores /etc/pam.conf
4415159 unix_scheme pam_chauthtok does not stack
4415162 unix_scheme pam_chauthtok too tightly coupled with passwd

It seems like we should really try with Solaris 9.

Re: pam_passwdqc, ssh and expired passwords

On Tue, Jul 02, 2002 at 02:45:19PM +1000, John Warburton wrote:
> 
> Hmm - good work Sun.
> 
> Looks like I will have to go back to cracklib for want of anything else.
> sigh.

Why does that help?  Are you able to get cracklib to verify passwords
changed through sshd or telnetd?  How, if the password management PAM
stack is broken in that respect?

Is Solaris 9 not an option for you?

>                     Solar                                                                                          
>                     Designer             To:     John Warburton <John.Warburton <at> asic.gov.au>                       
>                     <solar <at> openwa        cc:     pam-list <at> redhat.com                                               
>                     ll.com>              Fax to:                                                                   
>                                          Subject:     Re: pam_passwdqc, ssh and expired passwords                  
>                     29/06/2002                                                                                     
>                     03:19 AM                                                                                       
>                                                                                                                    
>                                                                                                                    
>                                                                                                                    
>                                                                                                                    
> 
> 
> 
> 
> ***
> This email message has been processed by MIMEsweeper

Using PAM passwd from web-enabled CGI

passwd that uses PAM complains that it's not running as root, even from
programs that are suid to root.  (This includes forked programs that
exec to passwd without invoking the bash 2.0 shell, which apparently
disables suid root when it starts.)

Can anyone suggest a method to change passwords from programs that
aren't logged in as root (i.e., ones that are just suid to root)?  Is
passwd the only program that can change the shadow password file
(especially using the MD5 passwords) ?

Thanks,
Dave

Re: Using PAM passwd from web-enabled CGI

On Tue, Jul 02, 2002 at 09:19:31PM -0700, David Retz wrote:
> passwd that uses PAM complains that it's not running as root, even from
> programs that are suid to root.  (This includes forked programs that
> exec to passwd without invoking the bash 2.0 shell, which apparently
> disables suid root when it starts.)

setuid programs run with the uid of the invoker, and the euid of
whatever its setuid to, this is how passwd knows whether its running
as root or a user.

> Can anyone suggest a method to change passwords from programs that
> aren't logged in as root (i.e., ones that are just suid to root)?  Is
> passwd the only program that can change the shadow password file
> (especially using the MD5 passwords) ?

if you setuid(0); in your suid wrapper before running passwd it will
then act as if run by root.

--

-- 
Ethan Benson
http://www.alaska.net/~erbenson/