Hi,

A second (minor) problem I ran into on MacOSX is out of scope for Postfix: a
cronjob which alters the permission of /usr/sbin/sendmail, causing postfix
to spit out a few warning when accepting local mail [1].

In short, when calling "diskutil repairPermissions /", the
/usr/sbin/sendmail permissions are changed. The log file says:

Group differs on ./usr/sbin/sendmail, should be 25, group is 0
Permissions differ on ./usr/sbin/sendmail, should be -r-sr-xr-x , they are
-r-xr-xr-x

Obviously, this is true, is sendmail was indeed the sendmail tool, but not
for the "sendmail" tool provided postfix. If the permissions are changed,
sendmail still accepts mail, but the security is (IMHO) compromised and it
rightfully spits out a few warnings [1].

So far, I haven't been able to circumvent this problem, mainly because I was
not able to find out where diskutil stores the permissions [2]. If someone
knows where this is stored, please let me know!! Regretably, Apple's website
does not mention diskutil, and it neither has a decent man page :-(.

On most MacOS X isntallations, this command (diskutil, a tool provided by
Apple, which is basically a shell version of the program "Disk Utility"
which has a GUI), is never called. However, there is a cron job which is
called "fixperms.pl" which calls this command weekly. This cron job is
installed by Macaroni, a cron job scheduler which also runs jobs when the
Mac was turned off at night (very useful to still rotate you log files on
your desktop Mac).

The obvious workaround is just to turn of this cronjob, or alter it to only
check the permissions and not alter them ("diskutil verifyPermissions /"). A
slightly less obvious (but very ugly) workaround is to still allow diskutil
to 'repair' the permissions on the disk and then change them back for
sendmail using chmod and chown in the perl script (yuck!). Regrettably,
setting the lock bit of the file (only possibly for HFS disks), did not do
the trick [3].

I don't think there is anything postfix can do about this, but I post it to
the list so that other people can find out.

Regards,
Freek Dijkstra

Notes:
[1] When the permissions are altered to -r-sr-xr-x, sendmail yells when
calling "/usr/sbin/sendmail userexample.com":
sendmail: warning: the Postfix sendmail command has set-uid root file
permissions
sendmail: warning: or the command is run from a set-uid root process
sendmail: warning: the Postfix sendmail command must be installed without
set-uid root file permissions

[2] I've tried to look for candidate files where diskutil stores
permissions. Grep sendmail didn't give any results, so they are probably not
stored in diskutils itself, but strings gave me two interesting strings:
"perms" and "diskutil/VerifyRepairPermissions.m". That was a dead end
though. Grepping on the whole contents of my system directory also didn't
give any results. Perhaps diskutils stores the names in UTF-16 instead of
UTF-8, or this information is stored in the resource fork instead of the
data fork, which grep also can't find.

[3] I though that the HFS lock even prevents the root from altering files.
Apperently that is true for the contents, but not for the attributes. At
least when I lock the file using
sudo /Applications/Developer/Tools/SetFile -a "L" /usr/sbin/sendmail
Diskutils can still change the permissions. Note that you can't use the
finder, but need this command line tool to change the lock bit, because
you're not allowed to do so: root owns the file, not you. SetFile (and
GetFileInfo) can be found on the (free) Apple Developers CD.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]