This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 480505 - pam_mail does not inform about mail
pam_mail does not inform about mail
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-17 17:43 EST by Michal Jaegermann
Modified: 2009-02-07 00:45 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-07 00:45:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
the current /etc/pam.d/sshd from a rawhide installation (618 bytes, text/plain)
2009-02-03 12:06 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2009-01-17 17:43:26 EST
Description of problem:

'man pam_mail' says "The pam_mail PAM module provides the "you have new mail" service to the user".  It used to with an "optional" line added to /etc/pam.d/sshd but it looks like that not anymore.  I just sent some mail both to root and a non-root accounts, logged via ssh and silence; even if test messages are there.

Also the same man page documents:

       debug
           Print debug information.

I thought that with this option I will find something in some file in /var/log/.  Try as I might I cannot see any traces anywhere.  Does that mean that there are not even attempts to use that module?

Version-Release number of selected component (if applicable):
pam-1.0.90-1.fc11

How reproducible:
always
Comment 1 Tomas Mraz 2009-02-03 08:02:25 EST
There are actually no debugging messages which would be sent to syslog in the pam_mail code. I should probably add some so we can trace whether the pam_mail is called or not.

Nevertheless I cannot reproduce your problem. The module seems to work fine here.
Can you please attach your /etc/pam.d/sshd?
Comment 2 Michal Jaegermann 2009-02-03 12:06:17 EST
Created attachment 330755 [details]
the current /etc/pam.d/sshd from a rawhide installation

Did I make a mistake to mark that for F10 when I meant for rawhide?  Apologies.  These mail notifications work for me just fine for F10 and earlier but stopped in rawhide.

The original last line in this file was simple

session    optional     pam_mail.so

The current state is a result of my attempts to try to figure out why this doe not have desired effects anymore.

Just sent on a test system some mail to myself and logged in via ssh after that and after typing 'mail' I can see:

"/var/spool/mail/michal": 1 message 1 new
>N  1 root                  Tue Feb  3 09:34  20/745   "testing"

but there was no "You have new mail" in a login banner.
Comment 3 Tomas Mraz 2009-02-04 05:14:35 EST
Do you have the symlink /var/mail -> /var/spool/mail? The default path for mail spool directory is defined by what is contained in /usr/include/paths.h _PATH_MAILDIR, but you can specify it on the pam_mail command line explicitly with the dir argument.

If it is not the problem above, could it be SELinux related? Try to update to the latest selinux-policy and do 'restorecon -r -v -F /var/spool/mail'. Did it change any contexts there?
Comment 4 Michal Jaegermann 2009-02-04 13:46:20 EST
> Do you have the symlink /var/mail -> /var/spool/mail?
$ ls -l  /var/mail
lrwxrwxrwx 1 root root 10 2008-09-07 13:36 /var/mail -> spool/mail

> but you can specify it on the pam_mail command line explicitly
> with the dir argument.

It is really unclear from 'man pam_mail' what should be a format of this argument so it will work across multiple accounts.  Should that be given as
/var/mail/$USER or /var/mail/<login>?  I tried to find some examples but in vain. 
In any case - for the sake of an experiment I hardwired it to /var/spool/mail/michal but this did not make any difference.

One would think that $MAIL environment really should be checked as not everybody may have that in a similar location.  Shell did inform me that I have new mail if this was really the case.

> could it be SELinux related?

SELinux is turned off on the installation in question.  Besides this used to work in the past.
Comment 5 Tomas Mraz 2009-02-04 14:49:35 EST
The $MAIL is probably not yet set when the module is running. The manpage should be improved I agree. The correct dir argument for your case is /var/mail or /var/spool/mail but as I said above in your case it should work fine without dir argument as /var/mail is the default.

Unfortunately I am currently out of ideas what's broken on your machine as I tried pam_mail on freshly updated rawhide machine and it worked fine.

You could perhaps try stracing the ssh process which calls the pam session modules.
Comment 6 Michal Jaegermann 2009-02-05 01:05:17 EST
> The correct dir argument for your case is /var/mail or /var/spool/mail

Err...  Not if you believe in what 'man pam_mail' says.  Quote:

If the mail spool file (be it /var/mail/$USER or a pathname given with
the dir= parameter) is a directory then pam_mail assumes it is in the
Maildir format.

I did not yet see /var/mail/$USER in a format other than mbox although I did make  on various systems procmail to deliver to something in a Maildir format.
Assuming that everybody on a system has mail delivered to $HOME/Maildir/
then, according to that manpage, this is easier; namely 'dir=~/Maildir'.
Only this is not the case here but I can surely try that.

strace on an ssh client will be not of a great help here.  I would expect that pam is called on a server side and that can become "interesting".
Comment 7 Tomas Mraz 2009-02-05 03:18:20 EST
Of course I meant server side ssh (sshd I know) process and not the client which doesn't know about the pam at all.

As I said in the comment #5 the manpage is less than ideal. The code works like this: if you have a ~ in the mailbox path then the mailbox path is modified so the ~ is replaced with the home dir from /etc/passwd. If you don't have it the user name is appended to the path specified by the dir argument. Then if the final path points to a file it is expected to be in the mailbox format, and if it is a directory it is expected to be in a maildir format.

So can you please try attaching the strace to the server processes? But do not attach it here as it can reveal the password hashes and so on. You have to be able to find from it whether it opens the appropriate file yourself.
Comment 8 Michal Jaegermann 2009-02-07 00:45:20 EST
Ugh! I found what was the problem.  Somehow "UsePAM no" crept into /etc/ssh/sshd_config (some experiments I forgot about).  And apparently pam indeed was not used and, as a side effect, nothing was checking new mail.  After sshd_config change new mail is reported again.  Apologies for the false alarm.

Should I open a new bug about 'man pam_mail' or this is not necessary?

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