Sendmail v8.14.2 on Fedora 8/9: problems with Group Writable issues

This is a discussion on Sendmail v8.14.2 on Fedora 8/9: problems with Group Writable issues within the SendMail forums in Other Technologies category; I am using sendmail version 8.14.2 on Fedora 8/9. I noticed that there has been some changes lately, when Fedora upgraded to this version whereas before, I never encountered this problem. The following is what I get when I attempted to start up the sendmail service: # service sendmail start Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 104: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory 451 4.0.0 /etc/mail/sendmail.cf: line 628: fileclass: cannot open '/etc/ mail/trusted-users': Group writable directory 451 4.0.0 /etc/mail/sendmail.cf: line 1762: Xspamassassin: local socket name /var/run/spamass-milter/spamass-milter.sock unsafe: Group writable directory 451 4.0.0 /etc/mail/sendmail.cf: line 1763: Xclamav-milter: local socket name ...

Go Back   Application Development Forum > Other Technologies > SendMail

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 08-19-2008, 07:36 PM
DanT
Guest
 
Default Sendmail v8.14.2 on Fedora 8/9: problems with Group Writable issues


I am using sendmail version 8.14.2 on Fedora 8/9.

I noticed that there has been some changes lately, when Fedora upgraded to
this version whereas before, I never encountered this problem. The
following is what I get when I attempted to start up the sendmail service:

# service sendmail start
Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 104: fileclass:
cannot open '/etc/mail/local-host-names': Group writable directory
451 4.0.0 /etc/mail/sendmail.cf: line 628: fileclass: cannot open '/etc/
mail/trusted-users': Group writable directory
451 4.0.0 /etc/mail/sendmail.cf: line 1762: Xspamassassin: local socket
name /var/run/spamass-milter/spamass-milter.sock unsafe: Group writable
directory
451 4.0.0 /etc/mail/sendmail.cf: line 1763: Xclamav-milter: local socket
name /var/run/clamav-milter/clamav.sock unsafe: Group writable directory

I followed a report on a blogger site and they say that in order to
get rid of the problems associated with the local-host-names and trusted-
users files, one has to:

Edit: /etc/mail/sendmail.cf
Change: Fw/etc/mail/local-hosts-names to: Fw-o /etc/mail/local-host-names
Change: Ft/etc/mail/trusted-users to: Ft-o /etc/mail/trusted-users

Why is that and why was this not handled via the sendmail.mc file?

My major issue is that my SpamAssassin and ClamAV no longer works and
I cannot figure out how to resolve this issue. I can service start both
of these programs, no problem, but it is sendmail that is being
restrictive.

I tried other ways noting in the Release notes, the changes allowing for
DontBlameSendmail with "TrustStickyBits" and applied sticky bits on the
/var/run/clamav-milter and /var/run/spamass-milter directories, changed
permissions/ownership, all to no avail. Keep in mind that the proper owners
are assigned to the directories and that in order to start these milters,
mode: 0700 on these directories are required otherwise the milters will
fail to startup.

Anyone have any idea what is going on?

Thanks!
DanT
Reply With Quote
  #2  
Old 08-19-2008, 09:00 PM
Grant Taylor
Guest
 
Default Re: Sendmail v8.14.2 on Fedora 8/9: problems with Group Writableissues

Group writable directory


On 08/19/08 18:36, DanT wrote:
> I followed a report on a blogger site and they say that in order to
> get rid of the problems associated with the local-host-names and
> trusted-users files, one has to:
>
> Edit: /etc/mail/sendmail.cf
> Change: Fw/etc/mail/local-hosts-names to: Fw-o /etc/mail/local-host-names
> Change: Ft/etc/mail/trusted-users to: Ft-o /etc/mail/trusted-users
>
> Why is that and why was this not handled via the sendmail.mc file?


I believe that the addition of the "-o" tells sendmail that these files
are optional and not to fail to start up if they exist. I'm betting
that if you add this option that even if you could start sendmail your
mail delivery would be severely limited by the lack of the contents of
the /etc/mail/local-host-names file.

As to why this has to be done in the .cf file verses the .mc file where
it should be, I have no clue. I /think/ it is possible to specify the
optionality in the .mc file, but I don't know how as I've never needed to.

> My major issue is that my SpamAssassin and ClamAV no longer works and
> I cannot figure out how to resolve this issue. I can service start
> both of these programs, no problem, but it is sendmail that is being
> restrictive.


I try to avoid any Red Hat derivative so I can't say for sure, but I'm
betting that SpamAssassin and ClamAV have a dependency on Sendmail.
Seeing as how Sendmail is not starting I could see how SpamAssassin and
ClamAV would also fail to automatically start.

> I tried other ways noting in the Release notes, the changes allowing
> for DontBlameSendmail with "TrustStickyBits" and applied sticky bits
> on the /var/run/clamav-milter and /var/run/spamass-milter
> directories, changed permissions/ownership, all to no avail. Keep in
> mind that the proper owners are assigned to the directories and that
> in order to start these milters, mode: 0700 on these directories are
> required otherwise the milters will fail to startup.


What are the permissions on the /etc/mail directory? Sendmail is very
good about telling you why it is upset. Look at the error message
again: "cannot open '/etc/mail/local-host-names': Group writable
directory". This means that said file can not be opened because the
directory that it is in is group writable. Remove the groups
permissions to write to the directory. Likewise with the trusted-users
file and the two milter sockets.

> Anyone have any idea what is going on?


I don't know what else is going on or why it happened, but I'd start by
looking at the permissions on the /etc/mail directory and the directory
that hold your milter sockets.



Grant. . . .

Reply With Quote
  #3  
Old 08-20-2008, 12:01 PM
DanT
Guest
 
Default Re: Sendmail v8.14.2 on Fedora 8/9: problems withGroup Writable issues

On Tue, 19 Aug 2008 20:00:13 -0500, Grant Taylor wrote:

> Group writable directory
>
>
> On 08/19/08 18:36, DanT wrote:
>> I followed a report on a blogger site and they say that in order to get
>> rid of the problems associated with the local-host-names and
>> trusted-users files, one has to:
>>
>> Edit: /etc/mail/sendmail.cf
>> Change: Fw/etc/mail/local-hosts-names to: Fw-o
>> /etc/mail/local-host-names Change: Ft/etc/mail/trusted-users to:
>> Ft-o /etc/mail/trusted-users
>>
>> Why is that and why was this not handled via the sendmail.mc file?

>
> I believe that the addition of the "-o" tells sendmail that these files
> are optional and not to fail to start up if they exist. I'm betting
> that if you add this option that even if you could start sendmail your
> mail delivery would be severely limited by the lack of the contents of
> the /etc/mail/local-host-names file.
>
> As to why this has to be done in the .cf file verses the .mc file where
> it should be, I have no clue. I /think/ it is possible to specify the
> optionality in the .mc file, but I don't know how as I've never needed
> to.
>
>> My major issue is that my SpamAssassin and ClamAV no longer works and I
>> cannot figure out how to resolve this issue. I can service start both
>> of these programs, no problem, but it is sendmail that is being
>> restrictive.

>
> I try to avoid any Red Hat derivative so I can't say for sure, but I'm
> betting that SpamAssassin and ClamAV have a dependency on Sendmail.
> Seeing as how Sendmail is not starting I could see how SpamAssassin and
> ClamAV would also fail to automatically start.
>
>> I tried other ways noting in the Release notes, the changes allowing
>> for DontBlameSendmail with "TrustStickyBits" and applied sticky bits on
>> the /var/run/clamav-milter and /var/run/spamass-milter directories,
>> changed permissions/ownership, all to no avail. Keep in mind that the
>> proper owners are assigned to the directories and that in order to
>> start these milters, mode: 0700 on these directories are required
>> otherwise the milters will fail to startup.

>
> What are the permissions on the /etc/mail directory? Sendmail is very
> good about telling you why it is upset. Look at the error message
> again: "cannot open '/etc/mail/local-host-names': Group writable
> directory". This means that said file can not be opened because the
> directory that it is in is group writable. Remove the groups
> permissions to write to the directory. Likewise with the trusted-users
> file and the two milter sockets.


But that is the point! NONE of the files or directories in /etc/mail has
group-writable permissions to begin with. That is why I was complaining
to begin with and that it is sendmail that got it bearings wrong - there
is no group-permissions anywhere in /etc directory, /etc/mail directory
nor any of the files contained in /etc/mail! Sendmail 8.14.2 has been
screwed up for a time and not sure how far back (I'd say back two releases)
because I NEVER HAD THIS PROBLEM when running Fedora-7/8 until recently
when 8.14.2 was released as an upgrade.

The milters run fine - they are started as a service SEPERATELY from
sendmail - they run fine! It is SENDMAIL that is barfing - it complains
of group-write permissions that IS NOT THERE! It is somehow seeing ghosts
that ARE NOT THERE!

>
>> Anyone have any idea what is going on?

>
> I don't know what else is going on or why it happened, but I'd start by
> looking at the permissions on the /etc/mail directory and the directory
> that hold your milter sockets.


See above. Did this, did that, and more. I even experimented with the
sticky bit support on directories that allow group/world write permissions
and THAT failed. SOMETHING IS WRONG WITH SENDMAIL!!!

> Grant. . . .


Grant, please understand this is not directed at you but at the
sendmail community - it seems that the Fedora group does not want
to deal with it, and I am hoping that someone in the sendmail.org
group sees this message. I'd like to get sendmail back and working
again.

Thanks!
Dan

Reply With Quote
  #4  
Old 08-20-2008, 01:08 PM
Robert Melson
Guest
 
Default Re: Sendmail v8.14.2 on Fedora 8/9: problems with Group Writable issues

In article <g8hf410rt0@enews4.newsguy.com>,
DanT <dant@cdkkt.com> writes:
> On Tue, 19 Aug 2008 20:00:13 -0500, Grant Taylor wrote:
>
>> Group writable directory
>>
>>
>> On 08/19/08 18:36, DanT wrote:
>>> I followed a report on a blogger site and they say that in order to get
>>> rid of the problems associated with the local-host-names and
>>> trusted-users files, one has to:
>>>
>>> Edit: /etc/mail/sendmail.cf
>>> Change: Fw/etc/mail/local-hosts-names to: Fw-o
>>> /etc/mail/local-host-names Change: Ft/etc/mail/trusted-users to:
>>> Ft-o /etc/mail/trusted-users
>>>
>>> Why is that and why was this not handled via the sendmail.mc file?

>>
>> I believe that the addition of the "-o" tells sendmail that these files
>> are optional and not to fail to start up if they exist. I'm betting
>> that if you add this option that even if you could start sendmail your
>> mail delivery would be severely limited by the lack of the contents of
>> the /etc/mail/local-host-names file.
>>
>> As to why this has to be done in the .cf file verses the .mc file where
>> it should be, I have no clue. I /think/ it is possible to specify the
>> optionality in the .mc file, but I don't know how as I've never needed
>> to.
>>
>>> My major issue is that my SpamAssassin and ClamAV no longer works and I
>>> cannot figure out how to resolve this issue. I can service start both
>>> of these programs, no problem, but it is sendmail that is being
>>> restrictive.

>>
>> I try to avoid any Red Hat derivative so I can't say for sure, but I'm
>> betting that SpamAssassin and ClamAV have a dependency on Sendmail.
>> Seeing as how Sendmail is not starting I could see how SpamAssassin and
>> ClamAV would also fail to automatically start.
>>
>>> I tried other ways noting in the Release notes, the changes allowing
>>> for DontBlameSendmail with "TrustStickyBits" and applied sticky bits on
>>> the /var/run/clamav-milter and /var/run/spamass-milter directories,
>>> changed permissions/ownership, all to no avail. Keep in mind that the
>>> proper owners are assigned to the directories and that in order to
>>> start these milters, mode: 0700 on these directories are required
>>> otherwise the milters will fail to startup.

>>
>> What are the permissions on the /etc/mail directory? Sendmail is very
>> good about telling you why it is upset. Look at the error message
>> again: "cannot open '/etc/mail/local-host-names': Group writable
>> directory". This means that said file can not be opened because the
>> directory that it is in is group writable. Remove the groups
>> permissions to write to the directory. Likewise with the trusted-users
>> file and the two milter sockets.

>
> But that is the point! NONE of the files or directories in /etc/mail has
> group-writable permissions to begin with. That is why I was complaining
> to begin with and that it is sendmail that got it bearings wrong - there
> is no group-permissions anywhere in /etc directory, /etc/mail directory
> nor any of the files contained in /etc/mail! Sendmail 8.14.2 has been
> screwed up for a time and not sure how far back (I'd say back two releases)
> because I NEVER HAD THIS PROBLEM when running Fedora-7/8 until recently
> when 8.14.2 was released as an upgrade.
>
> The milters run fine - they are started as a service SEPERATELY from
> sendmail - they run fine! It is SENDMAIL that is barfing - it complains
> of group-write permissions that IS NOT THERE! It is somehow seeing ghosts
> that ARE NOT THERE!
>
>>
>>> Anyone have any idea what is going on?

>>
>> I don't know what else is going on or why it happened, but I'd start by
>> looking at the permissions on the /etc/mail directory and the directory
>> that hold your milter sockets.

>
> See above. Did this, did that, and more. I even experimented with the
> sticky bit support on directories that allow group/world write permissions
> and THAT failed. SOMETHING IS WRONG WITH SENDMAIL!!!
>
>> Grant. . . .

>
> Grant, please understand this is not directed at you but at the
> sendmail community - it seems that the Fedora group does not want
> to deal with it, and I am hoping that someone in the sendmail.org
> group sees this message. I'd like to get sendmail back and working
> again.
>
> Thanks!
> Dan
>


No expert I. However, show us a directory listing for
/etc/mail, please. It might help to know both ownership
and permissions: ls -al /etc/mail, ls -ld /etc/mail.

Have you tried recompiling from source? If, indeed, your
sendmail installation - from an rpm, I'd guess - is screewed
up, then it's possible a rebuild directly from source will
solve your problem.

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
Thinking is the hardest work there is, which is the probable
reason so few engage in it. -- Henry Ford

Reply With Quote
  #5  
Old 08-20-2008, 02:51 PM
Kees Theunissen
Guest
 
Default Re: Sendmail v8.14.2 on Fedora 8/9: problems with Group Writableissues

DanT wrote:

> The milters run fine - they are started as a service SEPERATELY from
> sendmail - they run fine! It is SENDMAIL that is barfing - it complains
> of group-write permissions that IS NOT THERE! It is somehow seeing ghosts
> that ARE NOT THERE!


Unlikely.

Did you check the permissions off _all_ the directories in the paths
leading to your config files?
Or in other words: did you check the permissions of the root directory
too? The / directory is the only common element in all paths that
sendmail complains about. So I would start looking at that directory.

Show us the output of the command:
ls -ld / /etc /etc/mail /var /var/run \
/var/run/spamass-milter /var/run/clamav-milter



Regards,

Kees.

--
Kees Theunissen.
Reply With Quote
  #6  
Old 08-20-2008, 05:18 PM
DanT
Guest
 
Default Re: Sendmail v8.14.2 on Fedora 8/9: problems with Group Writableissues

On Wed, 20 Aug 2008 20:51:47 +0200, Kees Theunissen wrote:

> DanT wrote:
>
>> The milters run fine - they are started as a service SEPERATELY from
>> sendmail - they run fine! It is SENDMAIL that is barfing - it
>> complains of group-write permissions that IS NOT THERE! It is somehow
>> seeing ghosts that ARE NOT THERE!

>
> Unlikely.
>
> Did you check the permissions off _all_ the directories in the paths
> leading to your config files?
> Or in other words: did you check the permissions of the root directory
> too? The / directory is the only common element in all paths that
> sendmail complains about. So I would start looking at that directory.
>
> Show us the output of the command:
> ls -ld / /etc /etc/mail /var /var/run \
> /var/run/spamass-milter /var/run/clamav-milter
>


Oh my! THAT WAS IT!!! The ROOT drive was somehow set group
writable! OK - now it is time for me to go hide under a rock
in the Gobi (or Sahara) desert!

Thanks to all who responded! I have been humbled!
Sendmail is GREAT after all!

Dan
Reply With Quote
  #7  
Old 08-21-2008, 10:31 AM
Grant Taylor
Guest
 
Default Re: Sendmail v8.14.2 on Fedora 8/9: problems with Group Writableissues

On 08/20/08 16:18, DanT wrote:
> Oh my! THAT WAS IT!!! The ROOT drive was somehow set group
> writable! OK - now it is time for me to go hide under a rock in the
> Gobi (or Sahara) desert!


*nod* I expected such. I had just not gotten around to asking about
parent directories.

A directories parent permission are directly related to said directory.
The reasoning behind it is that just because I may not be able to
alter a given directory or files there in, I might have access to the
parent directory so that I can alter the directory that I want and
subsequently the files there in.

> Thanks to all who responded! I have been humbled! Sendmail is GREAT
> after all!


*nod*

You are welcome.



Grant. . . .

Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 08:35 PM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.