Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
I've installed qmail-ldap-1.03-r4.ebuild, and qmail-queue cannot write messeges in queue, because it doesn't have rights to do it. I did an strace and found this information 9269 execve("bin/qmail-queue", ["bin/qmail-queue"], ["RELAYCLIENT=", "RBLSMTPD=", "PWD=/var/qmail/supervise/qmail-smtpd", "RELAY_CTRL_DIR=/var /spool/relay-ctrl/allow", "PROTO=TCP", "RELAY_CTRL_DIR_FD=1023", "TCPREMOTEIP=200.254.135.12", "RELAY_CTRL_EXPIRY=1800", "TCPLOCALPORT=25", "SH LVL=1", "TCPLOCALIP=192.168.104.121", "LOGLEVEL=0", "TCPREMOTEPORT=37925", "_=/usr/bin/relay-ctrl-check"]) = 0 (snip) 9269 umask(033) = 022 9269 chdir("/var/qmail") = 0 9269 chdir("queue") = -1 EACCES (Permission denied) 9269 exit_group(62) = ? qmail-queue is a suid binary owned by qmailq, which is also the owner of /var/qmail/queue. /var/qmail is a ext3 partition, which DOES allows suid binaries on it. I feel this is the same problem Bug 37052 reports. Reproducible: Always Steps to Reproduce: 1. telnet localhost 25 2. simulate sending a bare message on smtp Actual Results: it returns error: "451 qq trouble creating files in queue (#4.3.0)" Expected Results: write the message in queue, then return a "250 ok" message on smtp ! What I can't understand is why qmail-queue can't access /var/qmail/queue, since 1) it is a suid binary; 2) both are owned by qmailq
please provide the output from: "ls -la /var/qmail/queue" And then check your permissions against these: # ls -la /var/qmail/queue drwxr-x--- 11 qmailq qmail 264 Mar 20 2003 . drwxr-xr-x 9 root root 248 Jan 20 2004 .. drwx------ 2 qmails qmail 48 Feb 23 13:07 bounce drwx------ 25 qmails qmail 600 Mar 20 2003 info drwx------ 25 qmailq qmail 600 Mar 20 2003 intd drwx------ 25 qmails qmail 600 Mar 20 2003 local drwxr-x--- 2 qmailq qmail 128 Mar 20 2003 lock drwxr-x--- 25 qmailq qmail 600 Aug 21 2004 mess drwx------ 2 qmailq qmail 48 Feb 23 14:05 pid drwx------ 25 qmails qmail 600 Mar 20 2003 remote drwxr-x--- 25 qmailq qmail 600 Mar 20 2003 todo
fmbraga@scadufax qmail $ sudo ls -la /var/qmail/queue/ Password: total 25 drwxr-x--- 11 qmailq qmail 109 Feb 8 15:47 . drwxr-xr-x 10 root root 1024 Feb 10 10:53 .. drwx------ 2 qmails qmail 6 Feb 20 09:04 bounce drwx------ 25 qmails qmail 4096 Feb 8 15:47 info drwx------ 25 qmailq qmail 4096 Feb 8 15:47 intd drwx------ 25 qmails qmail 4096 Feb 8 15:47 local drwxr-x--- 2 qmailq qmail 48 Feb 8 15:47 lock drwxr-x--- 25 qmailq qmail 4096 Feb 8 15:47 mess drwx------ 2 qmailq qmail 6 Feb 23 11:28 pid drwx------ 25 qmails qmail 4096 Feb 8 15:47 remote drwxr-x--- 25 qmailq qmail 4096 Feb 8 15:47 todo fmbraga@scadufax qmail $ sudo ls -la /var/qmail/bin/qmail-queue -rws--x--x 1 qmailq qmail 30248 Feb 8 16:42 /var/qmail/bin/qmail-queue fmbraga@scadufax qmail $
could you please re-run that strace as: "strace -ff -rtt -v" and attach the complete log?
Created an attachment (id=51996) [edit] strace -ff -rtt -v -s 256 -o tcpserver.str.5 strace begining with tcpserver, running as uid qmaild, gid nofiles
I don't know why, but if I follow your strace output correctly, your qmail-queue runs as qmaild:qmail and NOT qmailq:qmail. Could you also do the same strace command on qmail-start, and do a local mail delivery to trigger it (instead of a remote one like you have done in the existing strace). Lastly, could you try to reproduce this on non-ldap qmail? (I recommend the hard-masked r16 for testing).
I forgot to tell you, but... fmbraga@scadufax fmbraga $ uname -a Linux scadufax 2.6.10-hardened-r3 #1 Fri Feb 4 11:02:54 BRT 2005 i686 Intel(R) Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux fmbraga@scadufax fmbraga $ Could it be related to the hardened kernel somehow ? I'm suspecting on it because of: fmbraga@scadufax fmbraga $ cat /var/qmail/bin/tstsuid.sh #!/bin/sh ls -la /var/qmail/queue fmbraga@scadufax fmbraga $ ls -la /var/qmail/bin/tstsuid.sh -rwxr-xr-x 1 root root 36 Feb 24 07:56 /var/qmail/bin/tstsuid.sh fmbraga@scadufax fmbraga $ /var/qmail/bin/tstsuid.sh ls: /var/qmail/queue: Permission denied fmbraga@scadufax fmbraga $ sudo chown qmailq /var/qmail/bin/tstsuid.sh fmbraga@scadufax fmbraga $ sudo chmod +s /var/qmail/bin/tstsuid.sh fmbraga@scadufax fmbraga $ ls -la /var/qmail/bin/tstsuid.sh -rwsr-sr-x 1 qmailq root 36 Feb 24 07:56 /var/qmail/bin/tstsuid.sh fmbraga@scadufax fmbraga $ /var/qmail/bin/tstsuid.sh ls: /var/qmail/queue: Permission denied fmbraga@scadufax fmbraga $ sudo -u qmailq /var/qmail/bin/tstsuid.sh total 25 drwxr-x--- 11 qmailq qmail 109 Feb 8 15:47 . drwxr-xr-x 10 root root 1024 Feb 10 10:53 .. drwx------ 2 qmails qmail 6 Feb 20 09:04 bounce drwx------ 25 qmails qmail 4096 Feb 8 15:47 info drwx------ 25 qmailq qmail 4096 Feb 8 15:47 intd drwx------ 25 qmails qmail 4096 Feb 8 15:47 local drwxr-x--- 2 qmailq qmail 48 Feb 8 15:47 lock drwxr-x--- 25 qmailq qmail 4096 Feb 8 15:47 mess drwx------ 2 qmailq qmail 6 Feb 23 11:28 pid drwx------ 25 qmails qmail 4096 Feb 8 15:47 remote drwxr-x--- 25 qmailq qmail 4096 Feb 8 15:47 todo fmbraga@scadufax fmbraga $
This isn't a kernel issue. I changed kernel and it still does not work... fmbraga@scadufax fmbraga $ uname -a Linux scadufax 2.6.10-gentoo-r6 #1 SMP Thu Feb 24 09:48:56 BRT 2005 i686 Intel(R) Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux fmbraga@scadufax fmbraga $ cat /var/qmail/bin/tstsuid.sh #!/bin/sh ls -la /var/qmail/queue fmbraga@scadufax fmbraga $ ls -la /var/qmail/bin/tstsuid.sh -rwsr-sr-x 1 qmailq root 36 Feb 24 07:56 /var/qmail/bin/tstsuid.sh fmbraga@scadufax fmbraga $ /var/qmail/bin/tstsuid.sh ls: /var/qmail/queue: Permission denied fmbraga@scadufax fmbraga $
setuid doesn't work on scripts (kernel security reasons). construct your test case as a binary (a small C app). please provide the other strace data, and if the non-ldap qmail works.
its maybe not related, and maybe I am 100% wrong, but I had a similar problem with qmail-scanner until I noticed, that perl was compiled without the "suidperl" tag and therefore "suid" wasnt working on scripts. cu stonki
qmail-ldap-1.03-r5 is in cvs and should fix this, please reopen if it still fails
