Discussion:
2.2.14rc1 - dsync in backup mode still changes source permissions
Peter Mogensen
2014-10-10 08:05:33 UTC
Permalink
Hi,

It seems we are still able to reproduce this:
http://www.dovecot.org/list/dovecot/2014-May/096367.html

However... there's no longer any error-messages. It just silently
changes permissions on some dovecot files in the source maildir. (most
often dovecot-uidlist)

We're running dsync as root, with hardwired userdb values for other
reasons. So it has the OS permissions to change source. But still,
running in "backup" shouldn't change source ever, should it?

The command line is of this format - running on destination-host:


# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o
StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync
-o mail_home=/users/user/maildir"

/Peter
Timo Sirainen
2014-10-10 21:52:43 UTC
Permalink
Post by Peter Mogensen
http://www.dovecot.org/list/dovecot/2014-May/096367.html
However... there's no longer any error-messages. It just silently changes permissions on some dovecot files in the source maildir. (most often dovecot-uidlist)
We're running dsync as root, with hardwired userdb values for other reasons. So it has the OS permissions to change source. But still, running in "backup" shouldn't change source ever, should it?
It's not doing any changes to mailbox contents, but it's still updating the index/uidlist files as part of its normal operation.
Post by Peter Mogensen
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
You should use -u user at domain parameter in both sides so it drops root privileges.
Timo Sirainen
2014-10-10 22:22:58 UTC
Permalink
Post by Timo Sirainen
Post by Peter Mogensen
http://www.dovecot.org/list/dovecot/2014-May/096367.html
However... there's no longer any error-messages. It just silently changes permissions on some dovecot files in the source maildir. (most often dovecot-uidlist)
We're running dsync as root, with hardwired userdb values for other reasons. So it has the OS permissions to change source. But still, running in "backup" shouldn't change source ever, should it?
It's not doing any changes to mailbox contents, but it's still updating the index/uidlist files as part of its normal operation.
Post by Peter Mogensen
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
You should use -u user at domain parameter in both sides so it drops root privileges.
Oh, and reading the linked mail more closely, if the maildir S=sizes have problems then Dovecot attempts to fix them. It's the same as if you attempted to read the mails via any method. doveadm backup doesn't attempt to read the whole source maildir without any modifications, although it could, but that could cause performance problems.

Anyway, if you have broken S=sizes, you could try setting maildir_broken_filename_sizes=yes.
Peter Mogensen
2014-10-11 06:51:41 UTC
Permalink
Post by Timo Sirainen
It's not doing any changes to mailbox contents, but it's still updating the index/uidlist files as part of its normal operation.
I doesn't actually seem to change content of the files. Only
permissoins. But given that the docs says (or rather "said") explicitly:

"No changes are ever done to the source location."

I would expect operations on the "source" to be strictly read only -
including permissions.

Is the documentation intentionally changed to not make that promise anymore?
Post by Timo Sirainen
Post by Peter Mogensen
# dsync -R -o mail_home=/users/user/maildir backup ssh -c arcfour -o StrictHostKeyChecking=no -i /root/.ssh/id-rsa-dsync source-host "dsync -o mail_home=/users/user/maildir"
You should use -u user at domain parameter in both sides so it drops root privileges.
Yes... but the problem here is that the current userdb has accounts
which can be activated/de-activated and de-activating an account makes
the userdb act as it doesn't exist.
... which makes dsync skip it.

I realize that's a broken userdb, but the possible work-around was to
not do userdb lookups with dsync.

/Peter
Peter Mogensen
2014-10-13 05:36:43 UTC
Permalink
Post by Peter Mogensen
"No changes are ever done to the source location."
...
Post by Peter Mogensen
Is the documentation intentionally changed to not make that promise anymore?
I also notice that the "-o" for overriding userdb settings has been
removed from the documentation.

Is that intentionally?

/Peter

Loading...