Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
It seems that I have to make /var/mail world-writeable in order that procmail can correctly deliver the mails of users.
Procmail is called via the users' .forward file, and presently only delivers a mail if the users mailbox is not empty. Otherwise it complains of a lock failure and does not create the user's mailbox file (thus the mail is lost).
The present permissions of /var/mail are:
drwxrwxr-x root mail /var/mail
What is your opinion about this? Is there a better workaround?
That FAQ suggests to set the sticky bit on the word-writeable mail directory. (Although there are no procmailrcs in the home directories; does it mean that procmail gets rid of sgid mail if ANY program is called from /etc/procmailrc?)
I also put up this question at the procmail mailing list, where I was advised to check and set the setuid root permission of procmail. (I wonder if setuid root would work at all, since as procmail gets rid of the sgid mail permissions, it might more happily get rid of the root permissions as soon as the time comes).
Provided that the latter also works, which solution would you choose? (Well... I suppose you would choose none of the two. But say... if you
were threatened with death to choose one?)
I myself have to use such solutions because I do not have full control over the whole mail system; I must respect that sendmail (suid root) belongs to the competence of our so-called system administrator. (Two years were not enough for him to set up a working mail filter to protect 50 users sitting behind unpatched Outlook Expre$$es...)
LOL. If I was threatened with death I most certainly wouldn't think of prcmail's sgid behaviour first.
AFAIK "the time comes" when a ~/.forward and/or ~/.procmailrc are availabe: if ~/.procmailrc or ~/.forward are available, and the permissions are 0600 for rc (and mailbox) and 704 for forward, then change uid and drop sgid to owner's uid and gid. Commands from /etc/procmailrc use /etc/procmailrc's stated shell (of the user delivering to) and with DROPPRIVS=YES privs will be dropped to that of the user. At least that's what Ive tested (delivering to users mboxes tho, not /var/(spool/)mail, and with procmail defined as the MTA's LDA).
I think sgid mail and 1777 /var/mail are good but since a 0755 procmail will be dropping privs to user I'm not sure why they would suggest needing setuid root. I'm against setuid root binaries unless there's no proven workable alternative with lower privs, but then again I'm sure I'm forgetting something crucial about dotlocks or flocks but I ain't no procmail guru, ok? Could you post their reply in full?
Btw, if you say you're losing mail I would first get rid of ~/.forwards, and define a global failure rule in /etc/procmailrc that would drop to a default mbox or back into the queue. Yes, you *can* have if-else rules with procmail.
Btw2, did you define LOGVERBOSE=ALL to get a grip on the cause of not locking?
Strange, but suid root worked.
From a certain point of view it was better at the beginning:
Then things did not work, but I knew why.
Now that procmail runs as suid root things work but I do not know why...
I cannot avoid the users' .forward files, since they are the only way I can use to call procmail. As I mentioned before, I am not allowed to edit sendmail.cf, where mail is defined as the only LDA (our system administrator preferred that).
I prefer the suid root solution because it is the same method that our system administrator choosed for sendmail; thus I cannot be accused of doing something worse (e.g. disclosing the privacy of the mailboxes of users).