Re: [Dovecot] Maildir permissions and Solr re-indexing
Joseph Tam writes: > Michael Welsh Duggan writes: > >> All the files in my Maildir are owned by md5i:mail (I am md5i), and have >> 660 permissions. All directories have the same user:group permissions, >> and 770 with the setguid bit set. (That last may not be necessary, but >> ... >> >> doveadm(md5i): Error: >> fchown(/home/md5i/Maildir/.mail.test/dovecot.index.log.newlock, >> group=8(mail)) failed: Operation not permitted (egid=1000(md5i), >> group based on /home/md5i/Maildir/.mail.test - see >> http://wiki2.dovecot.org/Errors/ChgrpNoPerm) >> >> After this, each directory has a dovecot.index.log with md5i:md5i 600 >> permissions. > > I think the cause is clear enough: you (user=md5i/uid=1000) are not > part of group mail (gid=8), so the dovecot user process doing things on > your behalf cannot create index files that are anlogous to the mailbox > it's indexing. > > You can either > > 1) add "md5i" to group mail > 2) remove g+w permission on your mail files (making group > membership irrelevant) > 3) fiddle with "mail_privileged_group = mail", but I'm a little > hazy on all the ramifications of this. > > I don't know your particular circumstances, so I don't know which > is best. If (big if) nothing on your system (particularly the MTA) > requires access to your mail spool files by running as group=mail, > probably 2) is your best option. Thank you. 2) did the trick, and I think I understand how this works now. -- Michael Welsh Duggan (m...@md5i.com)
[Dovecot] Lowering Log Levels Back to Defaults
Greetings,
I'm sorry for asking what may be a really obvious question, but I'm
having a hard time turning off logging, or at least getting less verbose
logging. My dsync logs are about 7 MB daily, and I'm trying to get that
switched off. At one point I had it on a lower level of verbosity, and
I turned it up for debugging purposes, but now I cannot seem to turn it
back down, which is something I did many times before. For example the
logs are getting tons of Info level messages.
dsync(a...@globalchangemusic.org): Info: expunge: box=Trash, uid=61625,
msgid=, size=9586
In dovecot.conf I have commented out the following include, which used
to lower the log levels back to the defaults, but I've upgraded Dovecot
recently to 2.2.4 from 2.1 something:
#!include conf.d/10-logging.conf
I had the default levels raised in that config file.
I'm not sure this helps but:
[vmail@triata ~]# doveconf -n
# 2.2.4: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.18-194.32.1.el5xen x86_64 CentOS release 5.5 (Final) ext3
auth_mechanisms = plain login
mail_home = /vmail/%d/%n/home
mail_location = maildir:/vmail/%d/%n
mail_plugins = " mail_log notify"
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave
namespace {
inbox = yes
location =
prefix =
separator = /
type = private
}
passdb {
args = /etc/dovecot/dovecot-mysql.conf
driver = sql
}
plugin {
sieve = /vmail/%d/%n/sievescript
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-master {
group = vmail
mode = 0660
user = vmail
}
unix_listener auth-userdb {
mode = 0660
user = vmail
}
user = root
}
service imap-login {
process_min_avail = 3
service_count = 0
vsz_limit = 0
}
ssl_cert =
Re: [Dovecot] LMTP: userdb lookup - user-filter with variables
Am 31.07.2013 14:05, schrieb Burckhard Schmidt:
I tried to use dovcots lmtp instead of dovecot-lda.
postfix has in master.cf ... dovecot-lda -f ... -d ${user} to separate
the user part from user@hostname.domain.
So lookup of "user" succeeds in userdb (LDAP) done by dovecot-lda.
I have always local addresses like to=
postfix/lmtp[6579]: [ID 197553 mail.info] B3CDA66A16:
to=
With lmtp the userpart must be separated also. I tried user_filter
(LDAP) with %n, %Ln, %8n without success: userdb lookup:
user@hostname.domain doesn't exist)
Missing charachters "@.-" in auth_username_chars prevents
user@host.domain to be a valid address at all.
dovecot-2.1.17
I used "doveadm user h0094slk" and
"doveadm user h0094...@mailstore4.hu-berlin.de"
for my tests.
userdb {
driver = ldap
args = /usr/dovecot/etc/ldapuser.conf
}
and ldapuser.conf with
...
user_filter = (&(uid=%n) (objectClass=cmsAccount))
user_attrs = homeDirectory=home
I modified user_filter like uid=%Ln or uid=%8u
success for doveadm user h0094slk (because nothing to split)
userdb: h0094slk
home : /home/p0094/h0094slk
but no success for
doveadm user h0094...@mailstore4.hu-berlin.de
userdb lookup: user h0094...@mailstore4.hu-berlin.de doesn't exist
It looks for me like user_filter do not use variables at this point?
What I'm missing?
--
Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation
ZE Computer- und Medienservice der Humboldt-Universität zu Berlin
Postanschrift: Unter den Linden 6, 10099 Berlin
Standort: Rudower Chaussee 26; 12489 Berlin
Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959
Mail: bschm...@cms.hu-berlin.de
[Dovecot] LMTP: userdb lookup - user-filter with variables
I tried to use dovcots lmtp instead of dovecot-lda.
postfix has in master.cf ... dovecot-lda -f ... -d ${user} to separate
the user part from user@hostname.domain.
So lookup of "user" succeeds in userdb (LDAP) done by dovecot-lda.
I have always local addresses like to=
postfix/lmtp[6579]: [ID 197553 mail.info] B3CDA66A16:
to=
With lmtp the userpart must be separated also. I tried user_filter
(LDAP) with %n, %Ln, %8n without success: userdb lookup:
user@hostname.domain doesn't exist)
dovecot-2.1.17
I used "doveadm user h0094slk" and
"doveadm user h0094...@mailstore4.hu-berlin.de"
for my tests.
userdb {
driver = ldap
args = /usr/dovecot/etc/ldapuser.conf
}
and ldapuser.conf with
...
user_filter = (&(uid=%n) (objectClass=cmsAccount))
user_attrs = homeDirectory=home
I modified user_filter like uid=%Ln or uid=%8u
success for doveadm user h0094slk (because nothing to split)
userdb: h0094slk
home : /home/p0094/h0094slk
but no success for
doveadm user h0094...@mailstore4.hu-berlin.de
userdb lookup: user h0094...@mailstore4.hu-berlin.de doesn't exist
It looks for me like user_filter do not use variables at this point?
What I'm missing?
--
Mit freundlichen Grüßen --- Burckhard Schmidt
Abteilung Systemsoftware und Kommunikation
ZE Computer- und Medienservice der Humboldt-Universität zu Berlin
Postanschrift: Unter den Linden 6, 10099 Berlin
Standort: Rudower Chaussee 26; 12489 Berlin
Tel.: +49-30-2093-70058 Fax: +49-30-2093-2959
Mail: bschm...@cms.hu-berlin.de
Re: [Dovecot] LDA vs. LMTP
On 7/30/2013 8:37 PM, Ben Morrow wrote: > At 3PM -0700 on 30/07/13 you (Joseph Tam) wrote: >> Martin Burgraf writes: >> >>> And when it's running as root there is always the danger >>> of privilege escalation. LDA only runs when it's needed and since it >>> uses only user rights it shoudbe more harmless. >> >> I didn't contest the privilege separation aspect, as it a necessary >> design trade-off that one daemon doing things for all user will need >> overriding access. However, if this is a concern, you can virtualize >> all your users. LMTP can theoretically be subverted, but at least won't >> be as root. (I'm assuming LMTP stays as root, and not spawning off user >> processes to do the real work.) > > It doesn't stay as root; Dovecot's LMTP switches down to the user's uid > to perform delivery, including sieve scripts. The security concerns are > in fact very similar to LDA: for LDA delivery with (say) Postfix, you > have local(8) running as root and switching down to the user to invoke > the LDA, while for LMTP the Postfix lmtp(8) process runs as an > unprivileged Postfix user and the LMTP server runs as root and switches > down. > > AFAICS the LMTP conversation itself happens as root, though, which is a > shame; I might think twice about exposing it directly over the network. Shouldn't a few iptables/pf rules be able to substantially mitigate this potential problem? I.e. restrict which hosts a given host is allowed to speak LMTP with. -- Stan
