dovecot - Jun 2009 - ACLs, imap and launchd

I was going to experiment with ACLs when I faced a small problem.
It is just sufficient to enable the acl plugin for getting the  
behavior described hereafter.

When launching dovecot from the command line, one gets:

	sh-3.2# /usr/local/dovecot/sbin/dovecot -F
	ILoading modules from directory: /usr/local/dovecot-1.2.rc6/lib/ 
dovecot/imap
	IModule loaded: /usr/local/dovecot-1.2.rc6/lib/dovecot/imap/ 
lib01_acl_plugin.so
	IEffective uid=65534, gid=65534, home=/tmp
	Iacl: No acl setting - ACLs are disabled
	^C

In fact, a "dummy" imap process is run so as to fetch the capability  
(see master-settings.c); that process is run with an hardcoded uid/gid  
65534.
But this appears to be problematic when dovecot is started from  
launchd; clearly, launchd doesn't like arbitrary users, as it may be  
seen from system.log:

	org.dovecot[28382]: ^AILoading modules from directory: /usr/local/ 
dovecot-1.2.rc6/lib/dovecot/imap
	org.dovecot[28382]: ^AIModule loaded: /usr/local/dovecot-1.2.rc6/lib/ 
dovecot/imap/lib01_acl_plugin.so
	com.apple.launchd[1] (com.apple.launchd.peruser.65534[28384]):  
getpwuid("65534") failed
	com.apple.launchd[1] (com.apple.launchd.peruser.65534[28384]): PID  
28383 "imap" has no account to back it! Real/effective/saved UIDs:  
65534/65534/65534
	com.apple.launchd[1] (com.apple.launchd.peruser.65534[28384]): Exited  
with exit code: 1
	com.apple.launchd[1] (com.apple.launchd.peruser.65534): Throttling  
respawn: Will start in 10 seconds
	com.apple.launchd[1] (org.dovecot[28382]): Stray process with PGID  
equal to this dead job: PID 28383 PPID 1 imap
	com.apple.launchd[1] (org.dovecot[28382]): Exited abnormally: Alarm  
clock
	com.apple.launchd[1] (org.dovecot): Throttling respawn: Will start in  
5 seconds
	com.apple.launchd[1] (com.apple.launchd.peruser.65534[28386]):  
getpwuid("65534") failed
	com.apple.launchd[1] (com.apple.launchd.peruser.65534[28386]): Exited  
with exit code: 1
	com.apple.launchd[1] (com.apple.launchd.peruser.65534): Throttling  
respawn: Will start in 10 seconds
	... and so on ...

A workaround is to create the corresponding system user and group;  
launchd then doesn't complain anymore and everything seems to be  
working fine.

But I feel somewhat uncomfortable with that...
Wouldn't it be possible, for example, to consider using a system user  
such as "nobody" (unless I'm wrong, it should be defined on any
unix
flavor)?

TIA,
Axel


sh-3.2# /usr/local/dovecot/sbin/dovecot -n
# 1.2.rc6: /usr/local/etc/dovecot.conf
# OS: Darwin 9.7.0 i386
protocols: pop3 imap
ssl: no
disable_plaintext_auth: no
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/dovecot-1.2.rc6/libexec/dovecot/ 
imap-login
login_executable(imap): /usr/local/dovecot-1.2.rc6/libexec/dovecot/ 
imap-login
login_executable(pop3): /usr/local/dovecot-1.2.rc6/libexec/dovecot/ 
pop3-login
first_valid_uid: 2001
last_valid_uid: 65533
mail_location: mbox:~/_mailboxes:INBOX=~/_mailboxes/inbox
mail_debug: yes
mbox_read_locks: flock
mbox_write_locks: flock dotlock
mail_executable(default): /usr/local/dovecot-1.2.rc6/libexec/dovecot/ 
imap
mail_executable(imap): /usr/local/dovecot-1.2.rc6/libexec/dovecot/imap
mail_executable(pop3): /usr/local/dovecot-1.2.rc6/libexec/dovecot/pop3
mail_plugins(default): acl
mail_plugins(imap): acl
mail_plugins(pop3):
mail_plugin_dir(default): /usr/local/dovecot-1.2.rc6/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/dovecot-1.2.rc6/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/dovecot-1.2.rc6/lib/dovecot/pop3
pop3_lock_session(default): no
pop3_lock_session(imap): no
pop3_lock_session(pop3): yes
pop3_uidl_format(default): %08Xu%08Xv
pop3_uidl_format(imap): %08Xu%08Xv
pop3_uidl_format(pop3): %08Xv%08Xu
auth default:
   debug: yes
   passdb:
     driver: pam
     args: *
   userdb:
     driver: passwd

On Fri, 2009-06-26 at 10:33 +0200, Axel Luttgens wrote:
> Wouldn't it be possible, for example, to consider using a system user  
> such as "nobody" (unless I'm wrong, it should be defined on
any unix
> flavor)?
I guess. Done: http://hg.dovecot.org/dovecot-1.2/rev/2db158dd88be

v2.0 hopefully gets rid of the dump-capability completely.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090627/8c356ebb/attachment-0002.bin>

Le 28 juin 09 ? 03:54, Timo Sirainen a ?crit :
> On Fri, 2009-06-26 at 10:33 +0200, Axel Luttgens wrote:
>> Wouldn't it be possible, for example, to consider using a system
user
>> such as "nobody" (unless I'm wrong, it should be defined
on any unix
>> flavor)?
>
> I guess. Done: http://hg.dovecot.org/dovecot-1.2/rev/2db158dd88be
Wow! Thank you, Timo.

So, I tried the patch but unfortunately got this in system.log:

	org.dovecot[41675]: Error: User dump-capability is missing GID (see  
mail_gid setting)
	org.dovecot[41675]: Fatal: Invalid configuration in /usr/local/etc/ 
dovecot.conf
	com.apple.launchd[1] (org.dovecot[41675]): Exited with exit code: 89
	com.apple.launchd[1] (org.dovecot): Throttling respawn: Will start in  
10 seconds
	... and so on ...

Seems to be related to the checks in create_mail_process(), where it  
is relied on a value of -1 as an indicator for "unset".
Now, on OSX, user "nobody" has 4294967294/4294967294 for uid/gid, or  
-2/-2; on the other hand, group "nogroup" has a gid equal to  
4294967295, or... -1.

Defining some value for mail_gid in dovectot.conf, even if otherwise  
not needed, makes above problem disappear.

But again, this is somewhat artificial (the same way I had to create a  
system user with an uid/gid set to 65534/65534).

I thus tried this variant:

	} else {
		/* try to use some existing user. at least osx launchd
			doesn't like non-existing users. */
		struct passwd *pw;

		/* written that way, this could be extended to some other
			candidate system users (e.g. daemon?) */
		if ( ((pw = getpwnam("nobody")) != NULL)
				&& (pw->pw_uid != (uid_t)-1) && (pw->pw_gid !=
(gid_t)-1) )
		{
			args[0] = t_strdup_printf("uid=%s", dec2str(pw->pw_uid));
			args[1] = t_strdup_printf("gid=%s", dec2str(pw->pw_gid));
		}
  	}

and dovecot now launched without complaining, even with an unset  
mail_gid.

Of course, this "solves" the problem in the precise case of OSX; but  
should be OK with, for example, Redhat or Solaris as well.


Sincerely,
Axel