Sendmail 8.10.2 outsmarts itself
Tim
already bothered to do the research, and I have determined with
absolute certainty that I do not have a group writable directory.
However, I do have a somewhat unique situation (unique for most
regular users, perhaps, but not among other Mac OS X users).
You see, Mac OS X uses a clever trick to shield unsuspecting GUI users
from system directories where novices would do more harm than good. in
the case of /etc, this directory is really a link to /private/etc.
This way, the GUI side prevents the user from seeing anything within
this tree (as well as several other paths (bin, sbin, tmp, var, ...)
Anyway, my sendmail complains with:
451 4.0.0 /etc/mail/sendmail.cf: line 82: fileclass: cannot open
/private/etc/mail/local-host-names: Group writable directory
However:
-rw-r--r-- 1 root wheel 74 Dec 18 23:00 /etc/mail/local-host-names
drwxr--r-- 2 root wheel 1024 Dec 18 23:36 /etc/mail
drwxr-xr-x 7 root wheel 1024 Dec 12 21:45 /private
But it's the link that sendmail is too stupid to recognize:
lrwxrwxr-t 1 root admin 11 Dec 12 21:45 /etc -> private/etc
Of course the link is group writable! This cannot be changed! But the
actual directory is NOT writable. I believe sendmail doesn't have the
smarts to realize this. Anyone have any ideas or additional proof?
Per Hedeland
goo...@hoodfamily.org (Tim) writes:
>
>451 4.0.0 /etc/mail/sendmail.cf: line 82: fileclass: cannot open
>/private/etc/mail/local-host-names: Group writable directory
>
>However:
>
>-rw-r--r-- 1 root wheel 74 Dec 18 23:00 /etc/mail/local-host-names
>drwxr--r-- 2 root wheel 1024 Dec 18 23:36 /etc/mail
>drwxr-xr-x 7 root wheel 1024 Dec 12 21:45 /private
>
>But it's the link that sendmail is too stupid to recognize:
>
>lrwxrwxr-t 1 root admin 11 Dec 12 21:45 /etc -> private/etc
Actually, it would have to go out of its way to look at the permissions
of a symbolic link, and it doesn't do that as far as I know. What are
the permissions on / and /private/etc ?
--Per Hedeland
p...@bluetail.com
Tim
I meant to post /private/etc, but I didn't think of /:
drwxr-xr-x 7 root wheel 2048 Dec 19 00:10 /private/etc
drwxrwxr-t 18 root admin 1024 Dec 12 21:45 /
Either one of these two statements must be true:
If I remove group write permissions on /, I'm likely to hose up
software that needs to write to some path below /, or:
Sendmail is being way to anal about permissions because if /etc/mail
is not group writable and that's where my file in question is,
permissions are fine enough. This is my inclination, however this
whole concept is challenging my long-held beliefs about Unix file
system permissions.
A test is in order.
Well, I have just tested my theory:
I created a directory in /tmp:
drwxrwxrwt 5 root wheel 1024 Dec 20 00:00 /private/tmp
drwxrwxr-x 3 root unknown 1024 Dec 19 23:35 groupable
cd /tmp/groupable
echo hi > test
test: Permission denied.
chgrp wheel groupable
echo hi > test
-rw-r--r-- 1 tim wheel 3 Dec 20 00:03 test
I tried other things, too, but without belaboring the point: I cannot
create a new file nor write to an existing file if I don't have group
write permissions on the directory that immediately contains the file
(assuming, of course that I don't own the directory and "other"
permissions are non-writable as well).
Thus, sendmail is being unnecessarily anal is my modified :-)
conclusion.
Per Hedeland
goo...@hoodfamily.org (Tim) writes:
>I meant to post /private/etc, but I didn't think of /:
>
>drwxr-xr-x 7 root wheel 2048 Dec 19 00:10 /private/etc
>drwxrwxr-t 18 root admin 1024 Dec 12 21:45 /
>
>Either one of these two statements must be true:
>
>If I remove group write permissions on /, I'm likely to hose up
>software that needs to write to some path below /, or:
Maybe, maybe not - I know of at least one OS that shipped with many
group-writable directories out of "tradition" or maybe even mistake -
nothing actually needed it, and patches were later issued to correct the
problem.
>Sendmail is being way to anal about permissions because if /etc/mail
>is not group writable and that's where my file in question is,
>permissions are fine enough. This is my inclination, however this
>whole concept is challenging my long-held beliefs about Unix file
>system permissions.
Well, see my followup to your other posting on the same issue - in
general, if you can write to any directory in the path, you can create
a file with the contents of your choice anywhere below that directory.
>A test is in order.
>
>Well, I have just tested my theory:
>
>I created a directory in /tmp:
>
>drwxrwxrwt 5 root wheel 1024 Dec 20 00:00 /private/tmp
>drwxrwxr-x 3 root unknown 1024 Dec 19 23:35 groupable
>
>cd /tmp/groupable
>echo hi > test
>test: Permission denied.
>
>chgrp wheel groupable
>echo hi > test
>-rw-r--r-- 1 tim wheel 3 Dec 20 00:03 test
>
>I tried other things, too, but without belaboring the point: I cannot
>create a new file nor write to an existing file if I don't have group
>write permissions on the directory that immediately contains the file
>(assuming, of course that I don't own the directory and "other"
>permissions are non-writable as well).
In general, this is not true, see above. However your /tmp - and also
your /, which is unusual - are a special case in that they have the
"sticky" bit set, which in current Unices, when used on directories,
means that only the owner of a file or directory immediately below can
rename or remove it (this is *not* the "standard" semantics on Unix).
Thus you cannot rename /private or /tmp/groupable even if you have write
permission in / or /tmp, respectively, unless you are root (the owner of
/private and /tmp/groupable).
>Thus, sendmail is being unnecessarily anal is my modified :-)
>conclusion.
Well, I don't think it checks for the sticky bit on directories and/or
considers the consequences of it being set - maybe it should, but it
can't really assume the above semantics of it since not all Unices have
them, so it would need yet another OS/version-dependent #define. Maybe
include/sm/conf.h (in 8.12, sendmail/conf.h in older versions) will give
you an indication of a possible reason that this solution is not
preferred over "erring on the safe side".
--Per Hedeland
p...@bluetail.com
Tapani Tarvainen
> In article <1d2abc5d.0112...@posting.google.com>
> goo...@hoodfamily.org (Tim) writes:
> >drwxrwxr-t 18 root admin 1024 Dec 12 21:45 /
> >sendmail is being unnecessarily anal is my modified :-)
> >conclusion.
> Well, I don't think it checks for the sticky bit on directories and/or
> considers the consequences of it being set
If you tell it your system has reliable sticky bit, it
will check and trust it. Just put
define(`confDONT_BLAME_SENDMAIL', `TrustStickyBit')dnl
in your .mc file. (According to release notes that feature
has been there since 8.10.0.)
You might even put it in your OSTYPE definition file.
--
Tapani Tarvainen
Aaron Hall
<goo...@hoodfamily.org> wrote:
<snip>
> 451 4.0.0 /etc/mail/sendmail.cf: line 82: fileclass: cannot open
> /private/etc/mail/local-host-names: Group writable directory
>
> However:
>
> -rw-r--r-- 1 root wheel 74 Dec 18 23:00 /etc/mail/local-host-names
> drwxr--r-- 2 root wheel 1024 Dec 18 23:36 /etc/mail
> drwxr-xr-x 7 root wheel 1024 Dec 12 21:45 /private
>
> But it's the link that sendmail is too stupid to recognize:
>
> lrwxrwxr-t 1 root admin 11 Dec 12 21:45 /etc -> private/etc
>
> Of course the link is group writable! This cannot be changed! But the
> actual directory is NOT writable. I believe sendmail doesn't have the
> smarts to realize this. Anyone have any ideas or additional proof?
I was just fighting with sendmail over this myself on my OS X box.
First, those apparently aren't the only directories sendmail's checking
(although the error seems to imply the problem's somewhere along the
path to /etc/mail/local-host-names, that's not necessarily the case.)
There are a number of webpages that have instructions for dealing with
this.
I ended up at http://www.kung-foo.tv/xtips.shtml
...which said to remove group/world write permissions for all of:
/ /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
...and make sure they're chown'd to root.
Apple goes to the trouble of shipping sendmail with OS X, but can't
make it work out of the box. Sure was nice of 'em. :)
Hope this works,
Aaron
--
Aaron Hall : Preliminary operational tests were inconclusive.
aa...@vitaphone.net : (The damn thing blew up.)
Macintosh/UNIX Weenie, Network Flack, and...eh, whatever.
Tim
Thanks everyone for all the informative posts. Working with a
"shadowed" OS in Unix is a new concept to me. I'm guessing the guys at
Apple hadn't/haven't taken the time to dig into why they couldn't get
sendmail running without relaxing the safety net. Perhaps they will
change the permissions on these directories in an update or tweak the
config file as described in this thread.