Our company has always set our home directories with 750 permissions. We've just updated our internal email server to ubuntu 12.04/sendmail/dovecot/ESET antivirus (from slackware/sendmail/POP3a/ASSP) and now our .procmailrc files won't execute unless the home directory they live in is 755.

Any ideas? I don't see why I should have to use 755. I thought that procmail ran as the user for whom it was delivering mail(?)

barb

ETA: turns out 751 works as well. Still want to know why.

Your home directory should have octal 0750 to shield its contents. And .procmailrc is a resource file. It gets read and interpreted by procmail, not executed like a file with the executable bit set. Set the VERBOSE variable in your ~/.procmailrc, make it use a log file and test.

Thanks for the reply, Unspawn.

I do understand that we don't manually execute the .procmailrc file, that it is used by procmail. The problem I'm having is that unless I set those directory permissions at 755 or 751, the .procmailrc file is completely ignored. I have LOGFILE, VERBOSE, and LOGABSTRACT all set in the $HOME/.procmailrc file and absolutely nothing is written unless I open up the permissions on the $HOME directory. I can also set up an /etc/procmailrc file that works, but just can't get the $HOME/.procmailrc working for any of my users.

Sorry, misread that.


Can you run a strace on the process? See what it errors out on?

Thanks for the follow-up. I probably can't do the strace -- tomorrow is actually my last day at this job and I'm swamped with other issues. I just *really* wanted to understand this. Maybe I can get my heir to do it

Thanks again.

My guess would be that the test for the existence of .procmailrc might be done before switching to the user's UID for processing it. Frankly, that sounds like it would be a bug. Trying to get an strace of a process spawned by the mail delivery agent might be a challenge.

Then at least document the issue together with a link to this thread?

Yup, unSpawn, I definitely will. Actually, I looked at it with someone else last night and we determined this:

-- some process needs to check if the $HOME/.procmailrc file exists before trying to run it (hence needing the execute permission)
-- let's assume (for lack of anything better) that this process is run by root
-- the HOME directories are NFS mounted, so let's mount them no_root_squash to the mail server (running procmail)
-- voila!! It works now
-- set home dir permissions back to 750

Thanks for everyone's help!

1 members found this post helpful.

I would definitely report that as a bug against procmail. It should not be necessary to use no_root_squash or to open up the permissions on the home directory in order to use a user's .procmailrc in an NFS-mounted directory.

Likewise thanks for researching it and posting your findings and that on the last day of your current job.
Good luck with your new job, I hope it will prove to be profitable in many ways.

1 members found this post helpful.