[Dovecot] managesieve does call a wrong chown
After upgrading from dovecot 1.2.3, managesieve 0.11.8, sieve 0.1.11 to dovecot 1.2.9, managesieve 0.11.10 and sieve 0.1.14 users who do not have sieve rules yet and use managesieve for the first time do trigger error messages in the log file (for the authenticated user ggg in group syspr):
Jan 4 17:35:26 apollo dovecot: MANAGESIEVE(ggg): chown(/var/spool/sieve/ggg, -1, 0(root)) failed: Operation not permitted (egid=203(syspr)) Jan 4 17:35:26 apollo dovecot: MANAGESIEVE(ggg): sieve-storage: sieve_storage_verify_dir(/var/spool/sieve/ggg/tmp) failed: Operation not permitted Jan 4 17:35:26 apollo dovecot: MANAGESIEVE(ggg): Fatal: Failed to create sieve storage with data: /var/spool/sieve/ggg
Anyway the filter rules get created (used avelsieve) and the filter does get compiled when the first mail hits the rule. Subsequent invocations of managesieve do not try to change the group ownership of the directory. Looks like an annoyance only, but I would feel more comfortable w.o. the error messages.
the dovecot -n output: # 1.2.9: /etc/dovecot.conf # OS: Linux 2.6.18-164.6.1.el5 x86_64 Scientific Linux SL release 5.4 (Boron) protocols: imap imaps managesieve listen(default): * listen(imap): * listen(managesieve): *:2009 shutdown_clients: no login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(managesieve): /usr/libexec/dovecot/managesieve-login login_processes_count: 5 login_max_processes_count: 512 verbose_proctitle: yes mail_location: maildir:~/Maildir mmap_disable: yes fsync_disable: yes lock_method: dotlock maildir_copy_with_hardlinks: no mbox_read_locks: dotlock flock mbox_write_locks: dotlock flock mail_drop_priv_before_exec: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(managesieve): /usr/libexec/dovecot/managesieve mail_plugins(default): quota imap_quota zlib acl imap_acl listescape mail_plugins(imap): quota imap_quota zlib acl imap_acl listescape mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib64/dovecot/imap mail_plugin_dir(imap): /usr/lib64/dovecot/imap mail_plugin_dir(managesieve): /usr/lib64/dovecot/managesieve imap_client_workarounds(default): delay-newmail netscape-eoh tb-extra-mailbox-sep outlook-idle imap_client_workarounds(imap): delay-newmail netscape-eoh tb-extra-mailbox-sep outlook-idle imap_client_workarounds(managesieve): namespace: type: private separator: / location: maildir:~/Maildir inbox: yes list: yes subscriptions: yes namespace: type: private separator: / prefix: #mbox/ location: mbox:~/mail:CONTROL=~/mboxctrl hidden: yes list: no subscriptions: yes lda: postmaster_address: postmaster@ifh.de mail_plugins: sieve quota acl sieve_global_path: /var/spool/sieve/default.sieve quota_full_tempfail: yes auth_socket_path: /var/run/dovecot/auth-master fsync_disable: no auth default: mechanisms: gssapi gss-spnego login plain realms: IFH.DE DESY.DE cache_size: 32 passdb: driver: pam args: max_requests=1 cache_key=%u userdb: driver: passwd-file args: /etc/userdb socket: type: listen client: path: /var/run/dovecot/auth-client mode: 432 master: path: /var/run/dovecot/auth-master mode: 438 plugin: quota: maildir:User Quota quota_rule: *:storage=1000MB quota_rule2: INBOX:storage=1000MB quota_rule3: Trash:ignore acl: vfile:/etc/dovecot-acls:cache_secs=300 acl_shared_dict: file:/var/spool/shared/shared-mailboxes.db sieve_storage: /var/spool/sieve/%u sieve: /var/spool/sieve/%u.sieve quota_warning: storage=95%% /usr/local/bin/mailquota-warning.sh 95 quota_warning2: storage=80%% /usr/local/bin/mailquota-warning.sh 80 quota_warning3: storage=60%% /usr/local/bin/mailquota-warning.sh 60
-- Wolfgang Friebel Deutsches Elektronen-Synchrotron DESY Phone/Fax: +49 33762 77372/216 Platanenallee 6 Mail: Wolfgang.Friebel AT desy.de D-15738 Zeuthen Germany
On Mon, 4 Jan 2010, Wolfgang.Friebel@desy.de wrote:
After upgrading from dovecot 1.2.3, managesieve 0.11.8, sieve 0.1.11 to dovecot 1.2.9, managesieve 0.11.10 and sieve 0.1.14 users who do not have sieve rules yet and use managesieve for the first time do trigger error messages in the log file (for the authenticated user ggg in group syspr):
Jan 4 17:35:26 apollo dovecot: MANAGESIEVE(ggg): chown(/var/spool/sieve/ggg, -1, 0(root)) failed: Operation not permitted (egid=203(syspr)) Jan 4 17:35:26 apollo dovecot: MANAGESIEVE(ggg): sieve-storage: sieve_storage_verify_dir(/var/spool/sieve/ggg/tmp) failed: Operation not permitted Jan 4 17:35:26 apollo dovecot: MANAGESIEVE(ggg): Fatal: Failed to create sieve storage with data: /var/spool/sieve/ggg
replying to my own mail :-)
I did try to look into the code and see where this chown(dir, -1, 0) is coming from. It looks like the call is in mkdir_chown invoked in dovecot-1.2-managesieve-0.11.10/src/lib-sievestorage/sieve-storage.c line 249.
This piece of code is (if I understand it correctly) trying to set the group permissions according to the parent directory (assuming that the sieve storage is somewhere in the users home dir).
I did however choose to have a different dir layout, the sieve storage is under /var/spool/sieve/ which has permissions 1777 and is owned by root:root. Therefore the chown(dir, -1, 0) call is failing, as the parent dir does not belong to the group of the user but to root.
As the directory structure is nevertheless created (with the correct permissions), the next use of managesieve does no longer complain about wrong permissions and managesieve is correctly working.
Should I change my choice of sieve_dir as suggested in the wiki:
# Directory for :personal include scripts. The default is to use home directory. sieve_dir = %h/sieve
or is my setting a correct alternative?
Best regards
Wolfgang Friebel Deutsches Elektronen-Synchrotron DESY Phone/Fax: +49 33762 77372/216 Platanenallee 6 Mail: Wolfgang.Friebel AT desy.de D-15738 Zeuthen Germany
Wolfgang.Friebel@desy.de wrote:
On Mon, 4 Jan 2010, Wolfgang.Friebel@desy.de wrote:
This piece of code is (if I understand it correctly) trying to set the group permissions according to the parent directory (assuming that the sieve storage is somewhere in the users home dir).
Right.
I did however choose to have a different dir layout, the sieve storage is under /var/spool/sieve/ which has permissions 1777 and is owned by root:root. Therefore the chown(dir, -1, 0) call is failing, as the parent dir does not belong to the group of the user but to root.
Ok.
As the directory structure is nevertheless created (with the correct permissions), the next use of managesieve does no longer complain about wrong permissions and managesieve is correctly working.
Should I change my choice of sieve_dir as suggested in the wiki:
# Directory for :personal include scripts. The default is to use home directory. sieve_dir = %h/sieve
or is my setting a correct alternative?
I try to provide administrators like you with much flexibility, and I don't see why this kind of directory structure should be discouraged. Timo, any ideas? I guess I can implement a check to handles this situation gracefully.
Regards,
Stephan.
On 7.1.2010, at 11.44, Stephan Bosch wrote:
I did however choose to have a different dir layout, the sieve storage is under /var/spool/sieve/ which has permissions 1777 and is owned by root:root. Therefore the chown(dir, -1, 0) call is failing, as the parent dir does not belong to the group of the user but to root. Ok. I try to provide administrators like you with much flexibility, and I don't see why this kind of directory structure should be discouraged. Timo, any ideas? I guess I can implement a check to handles this situation gracefully.
I think this should be handled the same way as Dovecot does if mail root's parent directory is 01777. Now, I'm not sure what Dovecot actually currently does in that situation.. :) v1.1 might do whatever, I think v1.2+ would try to make it 0777 and shouldn't try to change the group to root, because the group doesn't matter since it's world-rwx anyway. That doesn't seem to be the best solution though. Maybe it should check if the +t bit is set and then use 0700 or maybe 0770 (maybe 01777 -> 0770, 01707 -> 0700?). I suppose I should write a function that does this so the code wouldn't have to be duplicated all around.
Timo Sirainen wrote:
I think this should be handled the same way as Dovecot does if mail root's parent directory is 01777. Now, I'm not sure what Dovecot actually currently does in that situation.. :) v1.1 might do whatever, I think v1.2+ would try to make it 0777 and shouldn't try to change the group to root, because the group doesn't matter since it's world-rwx anyway. That doesn't seem to be the best solution though. Maybe it should check if the +t bit is set and then use 0700 or maybe 0770 (maybe 01777 -> 0770, 01707 -> 0700?). I suppose I should write a function that does this so the code wouldn't have to be duplicated all around.
I'll wait for that one then.
Regards,
Stephan.
On Thu, 2010-01-07 at 14:06 +0100, Stephan Bosch wrote:
Timo Sirainen wrote:
I think this should be handled the same way as Dovecot does if mail root's parent directory is 01777. Now, I'm not sure what Dovecot actually currently does in that situation.. :) v1.1 might do whatever, I think v1.2+ would try to make it 0777 and shouldn't try to change the group to root, because the group doesn't matter since it's world-rwx anyway. That doesn't seem to be the best solution though. Maybe it should check if the +t bit is set and then use 0700 or maybe 0770 (maybe 01777 -> 0770, 01707 -> 0700?). I suppose I should write a function that does this so the code wouldn't have to be duplicated all around.
I'll wait for that one then.
My above text is completely wrong. When creating mail root directory, 0700 mode is used. I think Sieve should do the same thing when creating Sieve root directory.
I should probably at some point add a function that can be used to create these mail/sieve root dirs, but initially they would just create with 0700 mode too. Until someone complains and wants some other permissions to be used, and then I'd have to figure out some way to do that.
participants (3)
-
Stephan Bosch
-
Timo Sirainen
-
Wolfgang.Friebel＠desy.de