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
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?
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.
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?
> 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.
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.
> 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".
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.
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?