<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 1, 2019 at 11:37 PM Aki Tuomi <<a href="mailto:aki.tuomi@open-xchange.com">aki.tuomi@open-xchange.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>

  
   
 
 <div>
  <div>
   <br>
  </div>
  <blockquote type="cite">
   <div>
    On 01 February 2019 at 23:16 Mark Moseley <
    <a href="mailto:moseleymark@gmail.com" target="_blank">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="gmail-m_7741486802257096232io-ox-signature">
   ---
   <br>Aki Tuomi</div></div></blockquote><div><br></div><div><br></div><div>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? </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></div>