Bug 150131 - auth service cannot retrieve auth info
auth service cannot retrieve auth info
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-02 15:05 EST by Zing
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version: 3.1.8-68
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-19 06:12:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zing 2005-03-02 15:05:11 EST
Description of problem:
atd complains:
atd[3430]: Authentication service cannot retrieve authentication info

Version-Release number of selected component (if applicable):
3.1.8-64_FC3

How reproducible:
all the time

Steps to Reproduce:
1. run: 
at now
> ls
> ctrl-d
2. get error message in /var/log/cron

Actual results:
command run denied

Expected results:
command to run

Additional info:
this happens whether you're root or not.
down rev to 3.1.8-60 and everything works peachy
Comment 1 Jason Vas Dias 2005-03-02 15:47:44 EST
Firstly, atd never writes messages to /var/log/cron . Only the 
vixie-cron package binaries, crond and crontab, write messages
there. atd only writes messages to /var/log/messages.
Are you having problems running cron jobs too ?

What you are seeing seems to be that the PAM modules are not correctly
configured on your system.

at-3.1.8-64+ now uses PAM for access  control, and something is wrong
with your PAM setup.

Are you running commmands as a NIS or LDAP user ? Perhaps the NIS
daemons or LDAP services are unavailable.

Please append the output of this command to this bug:

 # egrep 'atd|pam' /var/log/messages | tail -100
 
 And the files:

 /etc/security/*.conf
 /etc/pam.d/atd
 /etc/pam.d/crond














Comment 2 Zing 2005-03-02 20:10:34 EST
this is just a regular user account, no nis/ldap.  cron works fine and
the messages are indeed coming from /var/log/cron (weird). 
/var/log/messages only has messages like this (looks like sysstat):
Mar  2 19:30:01 liberty crond(pam_unix)[6499]: session closed for user
root
Mar  2 19:40:01 liberty crond(pam_unix)[6587]: session opened for user
root by (uid=0)
Mar  2 19:40:02 liberty crond(pam_unix)[6587]: session closed for user
root

here's the atd pam cfg.  crond is the same.
#
# The PAM configuration file for the at daemon
#
#
auth       sufficient /lib/security/$ISA/pam_rootok.so
auth       required  /lib/security/$ISA/pam_stack.so service=system-auth
auth       required  pam_env.so
account    required  /lib/security/$ISA/pam_stack.so service=system-auth
session    required  /lib/security/$ISA/pam_stack.so service=system-auth
# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# session    required   pam_limits.so
#

/etc/pam.d/system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so

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

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so

everything in /etc/security/*.conf is commented out.

i remember having krb5-workstation on this machine at one time. hmm.
Comment 3 Adalbert Prokop 2005-03-03 08:52:37 EST
I've encountered the same bug. It seem to apply for any local users (like root),
but not for NIS users. I can reproduce this bug at home, but not at work, where
we use NIS - except for the "root" account.

My configuration is identical to this posted by Zing, except for
/etc/pam.d/system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5
shadow nis
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
Comment 4 Herbert Gasiorowski 2005-03-04 03:57:00 EST
I have the same problem here!

reinstalling at-3.1.8-60 and at works again (for root and nis accounts)

maybe the following from fedora-list can help:

On Wed, 2 Mar 2005, David L. Crow wrote:
...
Further investigation shows that most, if not all, PAM modules allow a
"debug" argument.  When I added this to all of the module lines in
/etc/pam.d/atd, I see the following syslog messages (/var/log/secure):

  Mar  3 22:51:00 waterloo pam_stack[31567]: called for "PAM_ACCOUNT"
  Mar  3 22:51:00 waterloo pam_stack[31567]: called from "atd"
  Mar  3 22:51:00 waterloo pam_stack[31567]: initializing
  Mar  3 22:51:00 waterloo pam_stack[31567]: creating child stack
`system-auth'
  Mar  3 22:51:00 waterloo pam_stack[31567]: creating environment
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing PAM_AUTHTOK
to child: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_CONV to child
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing
PAM_FAIL_DELAY to child: source not set
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing
PAM_OLDAUTHTOK to child: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing PAM_RHOST to
child: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing PAM_RUSER to
child: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_SERVICE to child
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_TTY to child
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_USER to child
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing
PAM_USER_PROMPT to child: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing data to child
  Mar  3 22:51:00 waterloo pam_stack[31567]: calling substack
  Mar  3 22:51:00 waterloo pam_stack[31567]: substack returned 9
(Authentication service cannot retrieve authentication info.)
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing PAM_AUTHTOK
to parent: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_CONV to parent
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing
PAM_FAIL_DELAY to parent: source not set
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing
PAM_OLDAUTHTOK to parent: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing PAM_RHOST to
parent: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing PAM_RUSER to
parent: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_SERVICE to parent
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_TTY to parent
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing PAM_USER to parent
  Mar  3 22:51:00 waterloo pam_stack[31567]: NOT passing
PAM_USER_PROMPT to parent: source is NULL
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing data back
  Mar  3 22:51:00 waterloo pam_stack[31567]: passing former back
  Mar  3 22:51:00 waterloo pam_stack[31567]: returning 9
(Authentication service cannot retrieve authentication info.)
  Mar  3 22:51:00 waterloo atd[31567]: Authentication service cannot
retrieve authentication info.
  Mar  3 22:51:00 waterloo pam_stack[31567]: freeing stack data for
`system-auth' service
Comment 5 Zing 2005-03-04 23:14:52 EST
after some pulling of hair, this seems to be an issue with the selinux patches.
 I'm running as selinux=permissive... atd runs as user daemon:daemon and as a
result getspname_r() in the pam library will always fail (permission denied). 
However, if one has selinux enabled though, it seems unix_chkpwd is exec'ed and
will allow the job to continue if it passes.

easiest workaround is to replace account line in /etc/pam.d/atd with:

account    required  /lib/security/$ISA/pam_permit.so

unfortunately, i'm not too sure what the right fix is.  you could wrap
pam_acct_mgmt() in atd.c with PRIV_START/PRIV_END...
Comment 6 Thomas Zehetbauer 2005-03-06 00:58:46 EST
I am too seeing this problem, having "acoount required pam_stack.so
service=system-auth" or "account required pam_unix.so" causes atd to
try opening /etc/shadow after dropping root privileges and gives
"Authentication service cannot retrieve authentication info."

I wonder how this mess could make it through QA :-(
Comment 7 David Kaplan 2005-03-07 02:28:47 EST
I have this same problem on machines with selinux turned on, but not on a
machine with selinux turned off.
Comment 8 Adalbert Prokop 2005-03-07 03:23:37 EST
(In reply to comment #7)
Cannot confirm this. SELinux ist turned off on runtime on my machine.
Comment 9 David Kaplan 2005-03-07 12:03:08 EST
Sorry, I was mistaken.  The machine for which at worked was a RH9, not a FC3
machine.  

I can confirm, however, that atd messages are being logged to /var/log/cron.  My
cron has:

Mar  7 08:58:48 localhost atd[5673]: Authentication service cannot retrieve
authentication info.

I can also confirm that changing the account line in /etc/pam.d/atd to:

account    required  /lib/security/$ISA/pam_permit.so

is an insecure, but effective, solution.
Comment 10 Jason Vas Dias 2005-03-07 14:45:32 EST
I have now fixed this bug . The only system on which I was able to
reproduce this problem had never had SELinux Enabled. All other 
systems which at one time had SELinux enabled did not show this
problem, regardless of whether SELinux was currently Enabled/Disabled.
This would appear to be a bug in PAM as pointed out in comment #5:
  "atd runs as user daemon:daemon and as a result getspname_r() 
   in the pam library will always fail (permission denied). 
   However, if one has selinux enabled though, it seems unix_chkpwd
   is exec'ed and will allow the job to continue if it passes.
  "
For some reason, once SELinux has been Enabled on a machine, even it
is not currently enabled, the PAM does allow the daemon:daemon user
to authenticate as other users. 
Until we fix this in PAM / SELinux,  atd should run as root; there is
now no harm in this because PAM & SELinux are used to gain the 
job owner's credentials and context before each job is run. 
crond also runs as root, and uses the same PAM and SELinux methods
to gain user credentials for each job.

Also, by default atd was using the LOG_CRON log facility, so its 
messages were appearing in /var/log/cron - it now uses the 
LOG_DAEMON log facility .

This is now fixed in : at-3.1.8-66_FC3 , which will shortly be 
available in FC3 updates, but which meanwhile can be downloaded
from:
    http://people.redhat.com/~jvdias/at/FC-3/
Comment 11 Adalbert Prokop 2005-03-07 15:09:10 EST
It seems to match my conditions: I've never enabled SELinux.
Comment 12 Zing 2005-03-07 21:13:06 EST
ummm, at-3.1.8-66_FC3 now breaks the at command for regular users (at least for me )

$ at now
at> echo blah
at> <EOT>
job 15 at 2005-03-07 21:10
Can't signal atd (permission denied)
Comment 13 Guillaume Perréal 2005-03-08 10:53:22 EST
I confirm #12. Same thing here :

$ at now
at> ls
at> <EOT>
job 588 at 2005-03-08 16:51
Can't signal atd (permission denied)
Comment 14 Guillaume Perréal 2005-03-08 11:03:50 EST
Additional info about #13 : the signaling error message doesn't
prevent the job to be run.
Comment 15 Jason Vas Dias 2005-03-08 14:50:44 EST
This is now fixed with at-3.1.8-68_FC3, available from:
   http://people.redhat.com/~jvdias/at/FC-3
Comment 16 Zing 2005-03-09 10:48:03 EST
at-3.1.8-68_FC3 works for me.
Comment 17 Walter Justen 2005-08-19 06:12:28 EDT
update package is published

Note You need to log in before you can comment on or make changes to this bug.