On Wednesday, April 6, 2016 4:42 PM, Viktor Dukhovni
<[email protected]> wrote:
>On Wed, Apr 06, 2016 at 01:38:46PM +0000, chaouche yacine wrote:
>
>> maildrop unix - n n - - pipe
>> flags=DRhu user=vmail argv=/var/vmail/maildropwrapper -V9 -d ${recipient}
>
>
> http://www.postfix.org/pipe.8.html
>
> user=username:groupname
> Execute the external command with the user ID and group ID of
> the specified username. The software refuses to execute com-
> mands with root privileges, or with the privileges of the mail
> system owner. If groupname is specified, the corresponding group
> ID is used instead of the group ID of username.
>
>Note, that pipe(8) is not the "login" program and does not execute
>programs with all the group memberships of the specified user.
>Only the primary group, or the explicitly selected "groupname" is
>available.
>
>--
> Viktor.
Thanks Viktor. I tried running it as vmail:daemon and honestly I had no idea
what would that do. The program could finally connect to the socket, as the
strace shows :
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/courier/authdaemon/socket"},
110) = 0
but it still failed to deliver the email, this time for another error :
connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/courier/authdaemon/socket"},
110) \
= 0
fcntl(3, F_SETFL, O_RDONLY) = 0
select(4, NULL, [3], NULL, {10, 0}) = 1 (out [3], left {9, 999998})
write(3, "PRE . login a.chaouche@algerian-"..., 41) = 41
select(4, [3], NULL, NULL, {30, 0}) = 1 (in [3], left {29, 999402})
read(3, "UID=113\nGID=1002\nHOME=/var/vmail"..., 8191) = 157
write(2, "maildrop: authlib: groupid=", 27maildrop: authlib: groupid=) = 27
write(2, "1002\0", 51002^@) = 5
write(2, "\n", 1) = 1
setgroups(1, [1002]) = -1 EPERM (Operation not permitted)
setgid(1002) = -1 EPERM (Operation not permitted)
dup(2) = 4
fcntl(4, F_GETFL) = 0x8401 (flags
O_WRONLY|O_APPEND|O_LARGEFILE)
close(4) = 0
write(2, "setgid: Operation not permitted\n", 32setgid: Operation not
permitted) = 32
close(2) = 0
close(1) = 0
exit_group(1)
I thought that since vmail is part of the daemon group the linux file
permission checking subsystem (or whatever that is) would allow the vmail user
to access that directory because he is a member of the daemon group. I still
don't understand why the groupid is important to set and I understand this is a
topic that is outside of postfix.
I ended up changing master.cf back as it was before (just user=vmail) and
changing the file permissions of the directory /var/run/courier/authdaemon like
this :
root@messagerie[10.10.10.20] /var/run/courier # chmod o+xr authdaemon/
So now I have
root@messagerie[10.10.10.20] /var/run/courier # ls
total 16K
drwxr-xr-x 2 daemon daemon 100 Apr 5 14:22 authdaemon
-rw-r--r-- 1 root root 5 Apr 5 14:22 imapd.pid
-rw------- 1 root root 0 Mar 7 16:39 imapd.pid.lock
-rw-r--r-- 1 root root 5 Apr 5 14:22 imapd-ssl.pid
-rw------- 1 root root 0 Mar 7 16:39 imapd-ssl.pid.lock
-rw-r--r-- 1 root root 5 Apr 5 14:22 pop3d.pid
-rw------- 1 root root 0 Mar 7 16:39 pop3d.pid.lock
-rw-r--r-- 1 root root 5 Apr 5 14:22 pop3d-ssl.pid
-rw------- 1 root root 0 Mar 7 16:39 pop3d-ssl.pid.lock
root@messagerie[10.10.10.20] /var/run/courier #
(authdaemon is world readable and executable)
Now maildrop finally works but at the cost of exposing this directory to the
world. I will be sending an e-mail to the cyrus mailing list and probably cc to
courier-imap for maildrop support to request comments about this.
