Re: The CONTROL problem with fs quotas.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: The CONTROL problem with fs quotas.

Timo Sirainen
On Fri, 2008-04-11 at 10:56 +0900, Jorgen Lundman wrote:

> We attempted to use CONTROL= with "%h", which would give us full
> directory hashing, however, we found that when it creates all the
> directories, it does so as the uid of the first user. So all following
> users (that hash in at least one part) will fail. Most likely because
> dovecot has already setuid()ed.  Pre-creating the hashes is not feasible.

What do you mean by %h? That expands to home directory. %Hu then would
give a hash of the entire user name.

> => Dovecot would call "mkdir_parents" on "%h" _before_ setuid, but
> create the final directory after.

Probably won't work well at least everywhere, since the same problem
would be with deliver. Also mail_drop_priv_before_exec=yes is useful
sometimes and then this wouldn't be possible either.

> OR, Dovecot support (at least 2 level) directory hashing when specifying
> CONTROL=%1/%2/%u

This is already possible. You could use first two letters of the
username (CONTROL=%1u/%2.1u/%u = u/s/user) or first two letters of a MD5
sum of the user (CONTROL=%1u/%2.1u/%u). Precreating the directories for
at least the MD5 sum should be easy.

> OR, The ability to disable dovecot-uidlist (in memory is fine). (Setting
> INDEX=memory does not work for CONTROL=).

For POP3 with pop3_uidl_format=%f this would be a possibility, but for
IMAP it would cause UIDVALIDITY to change for every login and cause IMAP
clients to re-download all messages all the time.

signature.asc (196 bytes) Download Attachment