Running: Ubuntu xenial, dovecot 2.2.36 I've been working on moving our user base from maildir to mdbox and trying to come up with solutions for things like moving emails around. In the past, with maildir, our support guys could just mv the files around and done. For mdbox, I've been working on getting things set up to use doveadm. One weirdness I've seen is that in imports (i.e. doveadm import), mail gets copied correctly but the resulting files are left with root ownership (I don't have 'service doveadm' 'user' set, so I guess it defaults to root). It's typically new m.* files as well as the dovecot.list.index and dovecot.list.index.log files. Looking at strace, no chown is done on them, nor was there setuid. The import had no trouble finding the correct user in the db, so I know that it knows the correct UID (I can see it just fine in debug logs too). And it will happily import to existing m.* files with no permissions issues (but considering it's running as root, I wouldn't expect it to). I've seen this using 'import' via IMAPc as well as with both src and dest on the same server. I can see this behavior in both scenarios. We have a single shared UID for mail, so especially in that "src/dest on same server" case, it's not a matter of UID-mismatch. It's a director setup, so all doveadm commands are coming through the director. If I run the import directly on the backend (which obviously would be a bad idea in real life), the ownership of new m.* files seems to be correct (I can see it setuid'ing to the correct UID from userdb in strace). If I run the import on the director, I can get a new root-owned file every time it rolls over to the next m.* file. Two questions: * Is that a bug? Is this expected behavior? Seems like the expected thing would be to use the UID from userdb and either do a setuid (just like running 'doveadm import' locally did) or chown'ing any new files to the correct UID. I always always assume misconfiguration (vs bug, since it's almost never a bug) but I'm baffled on this one. * I see that it's possible to set a user for service doveadm and the wiki even suggests that it's a good idea in a single UID setup. If there are no mailboxes with any other UIDs, *will setting 'service doveadm' to the same UID possibly break anything*? I can't think of why it would, but I want to be duly diligent. Plus I'm a little leery about closing the door to ever having additional UIDs for mailboxes. Happy to provide 'doveconf -n' but wanted to check first, before spending 15 minutes gently obfuscating it :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190201/8e3ca8b3/attachment.html>
<!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>
On Fri, Feb 1, 2019 at 11:37 PM Aki Tuomi <aki.tuomi at open-xchange.com> wrote:> > On 01 February 2019 at 23:16 Mark Moseley < moseleymark at gmail.com> wrote: > > > Running: Ubuntu xenial, dovecot 2.2.36 > > I've been working on moving our user base from maildir to mdbox and trying > to come up with solutions for things like moving emails around. In the > past, with maildir, our support guys could just mv the files around and > done. For mdbox, I've been working on getting things set up to use > doveadm. > > One weirdness I've seen is that in imports (i.e. doveadm import), mail > gets > copied correctly but the resulting files are left with root ownership (I > don't have 'service doveadm' 'user' set, so I guess it defaults to root). > It's typically new m.* files as well as the dovecot.list.index > and dovecot.list.index.log files. > > Looking at strace, no chown is done on them, nor was there setuid. The > import had no trouble finding the correct user in the db, so I know that > it > knows the correct UID (I can see it just fine in debug logs too). And it > will happily import to existing m.* files with no permissions issues (but > considering it's running as root, I wouldn't expect it to). > > I've seen this using 'import' via IMAPc as well as with both src and dest > on the same server. I can see this behavior in both scenarios. We have a > single shared UID for mail, so especially in that "src/dest on same > server" > case, it's not a matter of UID-mismatch. > > It's a director setup, so all doveadm commands are coming through the > director. If I run the import directly on the backend (which obviously > would be a bad idea in real life), the ownership of new m.* files seems to > be correct (I can see it setuid'ing to the correct UID from userdb in > strace). If I run the import on the director, I can get a new root-owned > file every time it rolls over to the next m.* file. > > Two questions: > > * Is that a bug? Is this expected behavior? Seems like the expected thing > would be to use the UID from userdb and either do a setuid (just like > running 'doveadm import' locally did) or chown'ing any new files to the > correct UID. I always always assume misconfiguration (vs bug, since it's > almost never a bug) but I'm baffled on this one. > > * I see that it's possible to set a user for service doveadm and the wiki > even suggests that it's a good idea in a single UID setup. If there are no > mailboxes with any other UIDs, *will setting 'service doveadm' to the same > UID possibly break anything*? I can't think of why it would, but I want to > be duly diligent. Plus I'm a little leery about closing the door to ever > having additional UIDs for mailboxes. > > Happy to provide 'doveconf -n' but wanted to check first, before spending > 15 minutes gently obfuscating it :) > > > Can you try > > doveadm import -U victim -u victim ... ? > --- > Aki Tuomi >Is that to test a generic 'import from sourceUser to dest user' (i.e. victim isn't literally the same in both -u and -U) or are you looking for a test where 'sourceUser' is the same email account as the destination? I just want to make sure I'm understanding right. The original tests (that result in the root-owned files) were all -U userA -u userB (i.e. different email accounts for src and dest), if you're asking about the former. If you're asking about the latter, I ran that and got the same result, a root-owned dovecot.list.index.log and dovecot.list.index and freshly created m.* files. The message count in the destination mailbox increases by the right number (no surprise since it's running as root), so the import itself is working. I should add that in both cases (different src/dest email account and same src/dest), the import works ok -- or at least increments the count in the index. It just leaves the email account in a broken state. Re-chown'ing it to the current permissions makes it happy again and the newly imported messages show up. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190204/d0fe7dcf/attachment.html>