<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
<br>
</div>
<blockquote type="cite">
<div>
On 01 February 2019 at 23:16 Mark Moseley <
<a href="mailto:moseleymark@gmail.com">moseleymark@gmail.com</a>> wrote:
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
Running: Ubuntu xenial, dovecot 2.2.36
</div>
<div>
<br>
</div>
<div>
I've been working on moving our user base from maildir to mdbox and trying
</div>
<div>
to come up with solutions for things like moving emails around. In the
</div>
<div>
past, with maildir, our support guys could just mv the files around and
</div>
<div>
done. For mdbox, I've been working on getting things set up to use doveadm.
</div>
<div>
<br>
</div>
<div>
One weirdness I've seen is that in imports (i.e. doveadm import), mail gets
</div>
<div>
copied correctly but the resulting files are left with root ownership (I
</div>
<div>
don't have 'service doveadm' 'user' set, so I guess it defaults to root).
</div>
<div>
It's typically new m.* files as well as the dovecot.list.index
</div>
<div>
and dovecot.list.index.log files.
</div>
<div>
<br>
</div>
<div>
Looking at strace, no chown is done on them, nor was there setuid. The
</div>
<div>
import had no trouble finding the correct user in the db, so I know that it
</div>
<div>
knows the correct UID (I can see it just fine in debug logs too). And it
</div>
<div>
will happily import to existing m.* files with no permissions issues (but
</div>
<div>
considering it's running as root, I wouldn't expect it to).
</div>
<div>
<br>
</div>
<div>
I've seen this using 'import' via IMAPc as well as with both src and dest
</div>
<div>
on the same server. I can see this behavior in both scenarios. We have a
</div>
<div>
single shared UID for mail, so especially in that "src/dest on same server"
</div>
<div>
case, it's not a matter of UID-mismatch.
</div>
<div>
<br>
</div>
<div>
It's a director setup, so all doveadm commands are coming through the
</div>
<div>
director. If I run the import directly on the backend (which obviously
</div>
<div>
would be a bad idea in real life), the ownership of new m.* files seems to
</div>
<div>
be correct (I can see it setuid'ing to the correct UID from userdb in
</div>
<div>
strace). If I run the import on the director, I can get a new root-owned
</div>
<div>
file every time it rolls over to the next m.* file.
</div>
<div>
<br>
</div>
<div>
Two questions:
</div>
<div>
<br>
</div>
<div>
* Is that a bug? Is this expected behavior? Seems like the expected thing
</div>
<div>
would be to use the UID from userdb and either do a setuid (just like
</div>
<div>
running 'doveadm import' locally did) or chown'ing any new files to the
</div>
<div>
correct UID. I always always assume misconfiguration (vs bug, since it's
</div>
<div>
almost never a bug) but I'm baffled on this one.
</div>
<div>
<br>
</div>
<div>
* I see that it's possible to set a user for service doveadm and the wiki
</div>
<div>
even suggests that it's a good idea in a single UID setup. If there are no
</div>
<div>
mailboxes with any other UIDs, *will setting 'service doveadm' to the same
</div>
<div>
UID possibly break anything*? I can't think of why it would, but I want to
</div>
<div>
be duly diligent. Plus I'm a little leery about closing the door to ever
</div>
<div>
having additional UIDs for mailboxes.
</div>
<div>
<br>
</div>
<div>
Happy to provide 'doveconf -n' but wanted to check first, before spending
</div>
<div>
15 minutes gently obfuscating it :)
</div>
</blockquote>
<div>
<br>
</div>
<div>
Can you try
</div>
<div>
<br>
</div>
<div>
doveadm import -U victim -u victim ... ?
</div>
<div class="io-ox-signature">
---
<br>Aki Tuomi
</div>
</body>
</html>