FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Red Hat Install

 
 
LinkBack Thread Tools
 
Old 11-29-2008, 04:52 PM
Bob McClure Jr
 
Default Procmail can't create mailbox

On Sat, Nov 29, 2008 at 09:28:38AM -0500, Mark Corsi wrote:
> My guess is that the server is seeing the process as 'other'. This leaves
> two solutions. One is to start the process with sudo so it starts as root. I
> would hazard a guess that this would open up an unexpected security hole
> since this is a mail process. The other solution is to make the process
> owner part of the group that owns that folder and make the folder group
> writable. Pretty sure the second solution will maintain security while
> accomplishing your goal.

Well, I already have a sufficiently secure work-around, but that works
around a symptom. I want to find out why an out-of-the-box
configuration quit working.

> -----Original Message-----
> From: redhat-install-list-bounces@redhat.com
> [mailto:redhat-install-list-bounces@redhat.com] On Behalf Of Bob McClure Jr
> Sent: Saturday, November 29, 2008 8:36 AM
> To: Getting started with Red Hat Linux
> Subject: Re: Procmail can't create mailbox
>
> On Sat, Nov 29, 2008 at 08:08:54AM -0500, Mark Corsi wrote:
> > One suggestion, rather than using permissions straight out of box. Try
> > setting the permissions to 777 (temporarily) to see if it is a permission
> > based issue.
>
> Yep, did that. It works, but that's not the way it's supposed to
> work. That's my interim dodge until I find The Right Solution(tm).
>
> > -----Original Message-----
> > From: redhat-install-list-bounces@redhat.com
> > [mailto:redhat-install-list-bounces@redhat.com] On Behalf Of Bob McClure
> Jr
> > Sent: Saturday, November 29, 2008 7:51 AM
> > To: Getting started with Red Hat Linux
> > Subject: Re: Procmail can't create mailbox
> >
> > On Fri, Nov 28, 2008 at 11:03:10PM -0500, Mark Corsi wrote:
> > > Not what you will want to hear, but...
> > >
> > > Use Sendmail. Older, more stable, runs 80% of all mail servers.
> >
> > Well, ubiquity does not make superiority. Note that Windows runs a
> > similar percentage of PCs. You wouldn't suggest that I go back to
> > that, would you?
> >
> > > Never ceases to amaze me when people always try to make a better widget
> > than
> > > one that works nearly perfectly.
> >
> > I barely got the hang of configuring sendmail when it was a single
> > daemon. When it went to two daemons, I never figured out which config
> > items went in which daemon's config. Postfix is much easier to figure
> > out, and IMHO more flexible.
> >
> > Note also that I think procmail is the problem, not postfix.
> >
> > > -----Original Message-----
> > > From: redhat-install-list-bounces@redhat.com
> > > [mailto:redhat-install-list-bounces@redhat.com] On Behalf Of Bob McClure
> > > Sent: Friday, November 28, 2008 8:24 PM
> > > To: Red Hat Install
> > > Subject: Procmail can't create mailbox
> > >
> > > Okay, this is driving me nuts. Procmail can't create a mailbox for a
> > > new user. This has come up on at least four servers I manage - FC5,
> > > FC6, CentOS 5.2, and now RedHat 5.2. They are all using Postfix and
> > > procmail to accept and deliver mail. All but one involve
> > > "bootlegging" in the users by copying over the normal users' passwd,
> > > shadow, group, and gshadow entries, as well as their home directories
> > > and/or the mail spool (/var/spool/mail). In the most recent case
> > > (RHEL 5), the /var/spool/mail directory is stock except that I created
> > > an LVM device and transferred /var/spool contents to it and then
> > > mounted it on /var/spool. The permissions are right out of the box:
> > >
> > > drwxrwxr-x 2 root mail 4096 Nov 28 04:02 /var/spool/mail
> > >
> > > I've done a web search and found nothing useful. My solution in each
> > > case has been to make /var/spool/mail world writable, and, in at least
> > > one case, added the sticky bit, to wit:
> > >
> > > drwxrwxrwt 3 root mail 20480 Nov 28 16:19 /var/spool/mail
> > >
> > > It works, but it's not the way it's supposed to work out of the box.
> > > Selinux is disabled on all machines. What am I missing?
> > >
> > > Cheers,
> > > --
> > > Bob McClure, Jr.
> >
> > Cheers,
> > --
> > Bob McClure, Jr.
>
> Cheers,
> --
> Bob McClure, Jr.

Cheers,
--
Bob McClure, Jr. Bobcat Open Systems, Inc.
bob@bobcatos.com http://www.bobcatos.com
For to us a child is born, to us a son is given, and the government
will be on his shoulders. And he will be called Wonderful Counselor,
Mighty God, Everlasting Father, Prince of Peace. Isaiah 9:6 (NIV)

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 12-01-2008, 05:11 PM
Rick Stevens
 
Default Procmail can't create mailbox

Bob McClure Jr wrote:

On Sat, Nov 29, 2008 at 09:28:38AM -0500, Mark Corsi wrote:

My guess is that the server is seeing the process as 'other'. This leaves
two solutions. One is to start the process with sudo so it starts as root. I
would hazard a guess that this would open up an unexpected security hole
since this is a mail process. The other solution is to make the process
owner part of the group that owns that folder and make the folder group
writable. Pretty sure the second solution will maintain security while
accomplishing your goal.


Well, I already have a sufficiently secure work-around, but that works
around a symptom. I want to find out why an out-of-the-box
configuration quit working.


Were there any diagnostics in the logs that may be of use? Did you
check /usr/bin/procmail and verified it was rwxr-xr-x (755), owned by
root, group of mail? Yes, /var/mail is a symlink to /var/spool/mail and
the link should be mode rwxrwxrwx (777).

/var/spool/mail itself should be owned by root, group of mail with mode
rwxrwxr-x (775). The files below that should be owned by the user whose
mailbox it is, group of mail with mode rw-rw---- (660).

I know of no extra things that may be affected by the addition of a user
via the "adduser" scripts that wouldn't be handled IF all of the user-
related files (home directories, hidden files, etc.) are present.

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Try to look unimportant. The bad guys may be low on ammo. -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 12-01-2008, 07:08 PM
Bob McClure Jr
 
Default Procmail can't create mailbox

On Mon, Dec 01, 2008 at 10:11:08AM -0800, Rick Stevens wrote:
> Bob McClure Jr wrote:
>> On Sat, Nov 29, 2008 at 09:28:38AM -0500, Mark Corsi wrote:
>>> My guess is that the server is seeing the process as 'other'. This leaves
>>> two solutions. One is to start the process with sudo so it starts as root. I
>>> would hazard a guess that this would open up an unexpected security hole
>>> since this is a mail process. The other solution is to make the process
>>> owner part of the group that owns that folder and make the folder group
>>> writable. Pretty sure the second solution will maintain security while
>>> accomplishing your goal.
>>
>> Well, I already have a sufficiently secure work-around, but that works
>> around a symptom. I want to find out why an out-of-the-box
>> configuration quit working.
>
> Were there any diagnostics in the logs that may be of use?

Only

Nov 28 18:45:46 lfvsfcp19080 postfix/local[30613]: 759B024035:
to=<bmcclure@dn.net>, orig_to=<root@dn.net>, relay=local, delay=3,
delays=0/0/0/3, dsn=5.2.0, status=bounced (can't create user output
file. Command output: procmail: Couldn't create "/var/mail/bmcclure" )

> Did you
> check /usr/bin/procmail and verified it was rwxr-xr-x (755), owned by
> root, group of mail?

-rwxr-xr-x 1 root mail 99128 Jul 12 2006 /usr/bin/procmail

> Yes, /var/mail is a symlink to /var/spool/mail and
> the link should be mode rwxrwxrwx (777).

lrwxrwxrwx 1 root root 10 Nov 21 20:43 /var/mail -> spool/mail

> /var/spool/mail itself should be owned by root, group of mail with mode
> rwxrwxr-x (775).

drwxrwxr-x 2 root mail 4096 Nov 28 04:02 /var/spool/mail

> The files below that should be owned by the user whose
> mailbox it is, group of mail with mode rw-rw---- (660).

-rw------- 1 root root 0 Nov 28 04:02 root
-rw-rw---- 1 root mail 0 Nov 21 20:52 root2
-rw-rw---- 1 rpc mail 0 Nov 21 20:47 rpc

> I know of no extra things that may be affected by the addition of a user
> via the "adduser" scripts that wouldn't be handled IF all of the user-
> related files (home directories, hidden files, etc.) are present.

drwx------ 25 bmcclure bmcclure 12288 Dec 1 04:02 /home/bmcclure
-rw-r--r-- 1 bmcclure apache 1716 Nov 28 21:40 /home/bmcclure/.procmailrc

I am mystified.

> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer ricks@nerd.com -
> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
> - -
> - Try to look unimportant. The bad guys may be low on ammo. -
> ----------------------------------------------------------------------

Cheers,
--
Bob McClure, Jr. Bobcat Open Systems, Inc.
bob@bobcatos.com http://www.bobcatos.com
"For I know the plans I have for you," declares the LORD, "plans to
prosper you and not to harm you, plans to give you hope and a future."
Jeremiah 29:11 (NIV)

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 12-01-2008, 08:21 PM
Rick Stevens
 
Default Procmail can't create mailbox

Bob McClure Jr wrote:

On Mon, Dec 01, 2008 at 10:11:08AM -0800, Rick Stevens wrote:

Bob McClure Jr wrote:

On Sat, Nov 29, 2008 at 09:28:38AM -0500, Mark Corsi wrote:

My guess is that the server is seeing the process as 'other'. This leaves
two solutions. One is to start the process with sudo so it starts as root. I
would hazard a guess that this would open up an unexpected security hole
since this is a mail process. The other solution is to make the process
owner part of the group that owns that folder and make the folder group
writable. Pretty sure the second solution will maintain security while
accomplishing your goal.

Well, I already have a sufficiently secure work-around, but that works
around a symptom. I want to find out why an out-of-the-box
configuration quit working.

Were there any diagnostics in the logs that may be of use?


Only

Nov 28 18:45:46 lfvsfcp19080 postfix/local[30613]: 759B024035:
to=<bmcclure@dn.net>, orig_to=<root@dn.net>, relay=local, delay=3,
delays=0/0/0/3, dsn=5.2.0, status=bounced (can't create user output
file. Command output: procmail: Couldn't create "/var/mail/bmcclure" )


Did you
check /usr/bin/procmail and verified it was rwxr-xr-x (755), owned by
root, group of mail?


-rwxr-xr-x 1 root mail 99128 Jul 12 2006 /usr/bin/procmail


Yes, /var/mail is a symlink to /var/spool/mail and
the link should be mode rwxrwxrwx (777).


lrwxrwxrwx 1 root root 10 Nov 21 20:43 /var/mail -> spool/mail


/var/spool/mail itself should be owned by root, group of mail with mode
rwxrwxr-x (775).


drwxrwxr-x 2 root mail 4096 Nov 28 04:02 /var/spool/mail


The files below that should be owned by the user whose
mailbox it is, group of mail with mode rw-rw---- (660).


-rw------- 1 root root 0 Nov 28 04:02 root
-rw-rw---- 1 root mail 0 Nov 21 20:52 root2
-rw-rw---- 1 rpc mail 0 Nov 21 20:47 rpc


I know of no extra things that may be affected by the addition of a user
via the "adduser" scripts that wouldn't be handled IF all of the user-
related files (home directories, hidden files, etc.) are present.


drwx------ 25 bmcclure bmcclure 12288 Dec 1 04:02 /home/bmcclure
-rw-r--r-- 1 bmcclure apache 1716 Nov 28 21:40 /home/bmcclure/.procmailrc

I am mystified.


Have you tried (as root):

touch /var/mail/bmcclure
chown bmcclure:mail /var/mail/bmcclure
chmod 660 /var/mail/bmcclure

Not sure if the adduser scripts create the empty mailbox or not. They
may...check that, they do. One of the possible exit values for useradd
is:

13 can’t create mail spool

Ok, now THAT'S subtle to find!
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Change is inevitable, except from a vending machine. -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 12-01-2008, 08:38 PM
Bob McClure Jr
 
Default Procmail can't create mailbox

On Mon, Dec 01, 2008 at 01:21:50PM -0800, Rick Stevens wrote:
> Bob McClure Jr wrote:
>> On Mon, Dec 01, 2008 at 10:11:08AM -0800, Rick Stevens wrote:
>>> Bob McClure Jr wrote:
>>>> On Sat, Nov 29, 2008 at 09:28:38AM -0500, Mark Corsi wrote:
>>>>> My guess is that the server is seeing the process as 'other'. This leaves
>>>>> two solutions. One is to start the process with sudo so it starts as root. I
>>>>> would hazard a guess that this would open up an unexpected security hole
>>>>> since this is a mail process. The other solution is to make the process
>>>>> owner part of the group that owns that folder and make the folder group
>>>>> writable. Pretty sure the second solution will maintain security while
>>>>> accomplishing your goal.
>>>> Well, I already have a sufficiently secure work-around, but that works
>>>> around a symptom. I want to find out why an out-of-the-box
>>>> configuration quit working.
>>> Were there any diagnostics in the logs that may be of use?
>>
>> Only
>>
>> Nov 28 18:45:46 lfvsfcp19080 postfix/local[30613]: 759B024035:
>> to=<bmcclure@dn.net>, orig_to=<root@dn.net>, relay=local, delay=3,
>> delays=0/0/0/3, dsn=5.2.0, status=bounced (can't create user output
>> file. Command output: procmail: Couldn't create "/var/mail/bmcclure" )
>>
>>> Did you
>>> check /usr/bin/procmail and verified it was rwxr-xr-x (755), owned by
>>> root, group of mail?
>>
>> -rwxr-xr-x 1 root mail 99128 Jul 12 2006 /usr/bin/procmail
>>
>>> Yes, /var/mail is a symlink to /var/spool/mail and
>>> the link should be mode rwxrwxrwx (777).
>>
>> lrwxrwxrwx 1 root root 10 Nov 21 20:43 /var/mail -> spool/mail
>>
>>> /var/spool/mail itself should be owned by root, group of mail with mode
>>> rwxrwxr-x (775).
>>
>> drwxrwxr-x 2 root mail 4096 Nov 28 04:02 /var/spool/mail
>>
>>> The files below that should be owned by the user whose
>>> mailbox it is, group of mail with mode rw-rw---- (660).
>>
>> -rw------- 1 root root 0 Nov 28 04:02 root
>> -rw-rw---- 1 root mail 0 Nov 21 20:52 root2
>> -rw-rw---- 1 rpc mail 0 Nov 21 20:47 rpc
>>
>>> I know of no extra things that may be affected by the addition of a user
>>> via the "adduser" scripts that wouldn't be handled IF all of the user-
>>> related files (home directories, hidden files, etc.) are present.
>>
>> drwx------ 25 bmcclure bmcclure 12288 Dec 1 04:02 /home/bmcclure
>> -rw-r--r-- 1 bmcclure apache 1716 Nov 28 21:40 /home/bmcclure/.procmailrc
>>
>> I am mystified.
>
> Have you tried (as root):
>
> touch /var/mail/bmcclure
> chown bmcclure:mail /var/mail/bmcclure
> chmod 660 /var/mail/bmcclure

Yeah, I know that works.

> Not sure if the adduser scripts create the empty mailbox or not.

Hmm. I've been assuming that it doesn't, but I just looked at
/etc/defaults/useradd, and indeed:

# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

> They
> may...check that, they do. One of the possible exit values for useradd
> is:
>
> 13 can’t create mail spool
>
> Ok, now THAT'S subtle to find!

Well, that would explain this server, and I know just how to fix it.
Now I have to go back to the others, because, on at least one of them,
useradd was not creating the mailbox. Gotta verify that's the case
and fix that.

Thanks for the clue.

> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer ricks@nerd.com -
> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
> - -
> - Change is inevitable, except from a vending machine. -
> ----------------------------------------------------------------------

Cheers,
--
Bob McClure, Jr. Bobcat Open Systems, Inc.
bob@bobcatos.com http://www.bobcatos.com
"For I know the plans I have for you," declares the LORD, "plans to
prosper you and not to harm you, plans to give you hope and a future."
Jeremiah 29:11 (NIV)

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 12-01-2008, 08:57 PM
Rick Stevens
 
Default Procmail can't create mailbox

Bob McClure Jr wrote:

On Mon, Dec 01, 2008 at 01:21:50PM -0800, Rick Stevens wrote:

Bob McClure Jr wrote:

On Mon, Dec 01, 2008 at 10:11:08AM -0800, Rick Stevens wrote:

Bob McClure Jr wrote:

On Sat, Nov 29, 2008 at 09:28:38AM -0500, Mark Corsi wrote:

My guess is that the server is seeing the process as 'other'. This leaves
two solutions. One is to start the process with sudo so it starts as root. I
would hazard a guess that this would open up an unexpected security hole
since this is a mail process. The other solution is to make the process
owner part of the group that owns that folder and make the folder group
writable. Pretty sure the second solution will maintain security while
accomplishing your goal.

Well, I already have a sufficiently secure work-around, but that works
around a symptom. I want to find out why an out-of-the-box
configuration quit working.

Were there any diagnostics in the logs that may be of use?

Only

Nov 28 18:45:46 lfvsfcp19080 postfix/local[30613]: 759B024035:
to=<bmcclure@dn.net>, orig_to=<root@dn.net>, relay=local, delay=3,
delays=0/0/0/3, dsn=5.2.0, status=bounced (can't create user output
file. Command output: procmail: Couldn't create "/var/mail/bmcclure" )


Did you
check /usr/bin/procmail and verified it was rwxr-xr-x (755), owned by
root, group of mail?

-rwxr-xr-x 1 root mail 99128 Jul 12 2006 /usr/bin/procmail


Yes, /var/mail is a symlink to /var/spool/mail and
the link should be mode rwxrwxrwx (777).

lrwxrwxrwx 1 root root 10 Nov 21 20:43 /var/mail -> spool/mail


/var/spool/mail itself should be owned by root, group of mail with mode
rwxrwxr-x (775).

drwxrwxr-x 2 root mail 4096 Nov 28 04:02 /var/spool/mail


The files below that should be owned by the user whose
mailbox it is, group of mail with mode rw-rw---- (660).

-rw------- 1 root root 0 Nov 28 04:02 root
-rw-rw---- 1 root mail 0 Nov 21 20:52 root2
-rw-rw---- 1 rpc mail 0 Nov 21 20:47 rpc


I know of no extra things that may be affected by the addition of a user
via the "adduser" scripts that wouldn't be handled IF all of the user-
related files (home directories, hidden files, etc.) are present.

drwx------ 25 bmcclure bmcclure 12288 Dec 1 04:02 /home/bmcclure
-rw-r--r-- 1 bmcclure apache 1716 Nov 28 21:40 /home/bmcclure/.procmailrc

I am mystified.

Have you tried (as root):

touch /var/mail/bmcclure
chown bmcclure:mail /var/mail/bmcclure
chmod 660 /var/mail/bmcclure


Yeah, I know that works.


Not sure if the adduser scripts create the empty mailbox or not.


Hmm. I've been assuming that it doesn't, but I just looked at
/etc/defaults/useradd, and indeed:

# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes


They
may...check that, they do. One of the possible exit values for useradd
is:

13 can’t create mail spool

Ok, now THAT'S subtle to find!


Well, that would explain this server, and I know just how to fix it.
Now I have to go back to the others, because, on at least one of them,
useradd was not creating the mailbox. Gotta verify that's the case
and fix that.

Thanks for the clue.


No problem. IIRC, procmail runs as the recipient's user and group. I
believe some systems have the procmail binary's set-group-ID bit set
("chmod g+s /usr/bin/procmail") which would make it run as group "mail".
That'd get around the lack of a world-write bit set on /var/spool/mail.
For the machines where it worked, see if that's true. procmail would
show up "rwxr-sr-x", I think.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- "Microsoft is a cross between The Borg and the Ferengi. -
- Unfortunately they use Borg to do their marketing and Ferengi to -
- do their programming." -- Simon Slavin -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 

Thread Tools




All times are GMT. The time now is 02:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org