Jamal Mubarak:
> 12181/0x403d0: execve(0x100112280, 0x100112380, 0x100200010) = -1
> Err#1
> 12181/0x403d0: stat64("/usr/sbin/postdrop\0", 0x7FFF5FBFF100, 0x2)
> = 0 0
> 12181/0x403d0: write(0x2, "sendmail: fatal: execvp /usr/sbin/postdrop:
> Operation not permitted\n\0", 0x44) = 68 0
execve() fails with error number 1. You can look that number up in
/usr/include/sys/errno.h (or whatever the pathname is on MacOS).
But, MacOS is a descendant of FreeBSD, and on my machine:
#define EPERM 1 /* Operation not permitted */
Now the question is why execve() fails with EPERM.
On UNIX systems, EPERM does not report a file permission problem.
Instead:
1 EPERM Operation not permitted. An attempt was made to perform an oper-
ation limited to processes with appropriate privileges or to the
owner of a file or other resources.
For example, only the owner (or root) can change the owner or
permissions of a file; everyone gets an EPERM error. The same error
is returned when a non-root process attempts to raise some resource
limit beyond its hard limit.
Unfortunately, I see no EPERM error in the FreeBSD exec.c library
module or in the kern_exec.c kernel side. Perhaps MacOS has "extra
security" features similar to Systrace or AppArmor that interfere
with Postfix operation, or you are using a weird file system that
burps errors.
Wietse
