Prev: VICTORY TELECOM
Next: Message with no recipients
From: John Chajecki on 4 May 2010 04:41
Over the weekend I re-discovered the strace utility...

Here is the tail of strace on the sendmail child process, pid obtained after
telnet to port 25 and inititating a mail transfer session. Sender accepted,
recipient Ok. Data accepted Ok and e-mail queued for delivery. Sendmail
corectly references the 'd' and 'q' files in the unlink statements (sorry
not sure what the 'x' one is) but in respect of where is './'?

The main problem though is obviously because sendmail does not have
permissions to setuid root when it is running as a non root user (i.e.
smmta). But why is it trying to setuid root in the first place?

/var/spool/mqueue is owned by smmta. The only place where root ownership
appears is /var/spool/mail:

lrwxrwxrwx 1 root root 7 2009-09-29 08:17 mail -> ../mail

but I can't seem to change this. /var/mail is owned by root:

drwxrwsrwt 2 root mail 4096 2010-05-04 09:29 mail

but I've also tried chown'ing this to smmta but got the same result. When
running sendmail as root, this evidently should be owned by rrot, but when
sendmail is running as another user, should it be owned by that user?

Here is the tail of the strace:

connect(5, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("212.159.13.49")}, 28) = 0
fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
gettimeofday({1272924260, 144408}, NULL) = 0
poll([{fd=5, events=POLLOUT}], 1, 0) = 1 ([{fd=5, revents=POLLOUT}])
john(a)altair:~/trace$ tail trace.txt
fstat64(2, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
alarm(0) = 0
rt_sigprocmask(SIG_UNBLOCK, [ALRM], [], 8) = 0
time(NULL) = 1272924290
time(NULL) = 1272924290
unlink("./dfo43M3H1n004927") = -1 ENOENT (No such file or
directory)
unlink("./qfo43M3H1n004927") = -1 ENOENT (No such file or
directory)
unlink("./xfo43M3H1n004927") = -1 ENOENT (No such file or
directory)
setuid32(0) = -1 EPERM (Operation not
permitted)
exit_group(0) = ?

From: John Chajecki on 4 May 2010 08:31
Sorry! Seems I stuck this onto the wrong thread!

Just in case someone else comes across this problem on Debian Linux, here is
the solution I found:

It seems that on Debian, sendmail is hacked to run something called
sensible-mda rather than mail.local. This executable determines which local
mailer to use depending on what MTA is installed. When building my own .mc
file I had to add the following to match the configuration of the
originally
supplied sendmail.cf file.:

FEATURE(local_lmtp)dnl
define(`LOCAL_MAILER_PATH', `/usr/sbin/sensible-mda')dnl
define(`LOCAL_MAILER_FLAGS', `lsDFMAw5:/|@qPn9S')dnl
define(`LOCAL_MAILER_ARGS', `sensible-mda $g $u $h ${client_addr}')dnl

When complied and run, sendmail now delivers locally as expected without
permission errors.

 | 
Pages: 1
Prev: VICTORY TELECOM
Next: Message with no recipients