On 15.5.2007, at 5.16, John Robinson wrote:

One possibility would be to set "uid_file=/vmail/%d gid_file=/ vmail/%d". I guess that would be good. Added to TODO, but I'm not sure when I get
around to implementing it.

Something like the attached?

Otherwise it's OK, but I'd want it to work with all userdbs. Looks like the code doesn't currently support doing that in any easy way. With passdbs it'd have been easy to use auth_request_set_field(). I guess I'll add a similar auth_request_add_userdb_field() for CVS HEAD.

[1] Use uid_file=/vmail/%d and login with domain ../etc/passwd and you end up looking at /etc/passwd. I don't know whether this matters: it's only doing a stat(), hopefully dovecot won't let you check mail as root, and anyway presumably the user has already had their password checked by now, and someone logging in as [EMAIL PROTECTED]/etc/ passwd or whatever would have failed a password check.

Right.

Hmm. Although this makes me think about deliver.. If using PAM/ checkpassword and userdb static, Dovecot can't verify that the user exists. Now if the username or domain contains ../ in it, the %n and % d variables in mail location will contain ../ also, which could mean that deliver can write to locations where it's not ever supposed to be writing anything.

I think the main problem is that username validations and translations are done only for authentications, not for deliver's userdb lookups. I guess I'll have to change this. After that '/' will be in invalid character list by default.

+                               auth_request_log_info(auth_request, 
"static-userdb",
+                                                     "Can't stat uid_file %s: 
%s",
+                                                     value, strerror(errno));

Instead of %s strerror() you can use %m which does the same.



Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to