[Dovecot] Feature request for maildir style boxes
greetings,
i'd like to ask for a certain feature request. dovecot:maildir_uidlist_recreate() to set the gid of new files based on the parent directory group ownership and normally that's desired, an appropriate security method. on our server, we use directory permissions to more stringently isolate access between users and services. we have three group ids used for this, and i'll use my name as example.
Oct 05 13:44:30 imap(david): Error:fchown(/home/david/.maildir/dovecot-uidlist.tmp, -1, 497(net-mail)) failed: Operation not permitted (egid=1234(david), group based on /home/david/.maildir)
Colt log # ls -ld /home/ /home/david /home/david/public_html/ /home/david/.maildir /home/david/.maildir/cur|awk '{printf "%s %5s %9s %s\n", $1,$3,$4,$9}'
drwxr-xr-x root root /home/
drwx--x--- david net-all /home/david
drwxr-x--- david net-mail /home/david/.maildir
drwx------ david david /home/david/.maildir/cur
drwxr-x--- david net-web /home/david/public_html/the purpose of this is to prevent undesired access to personal files. users cannot 'cd' or 'ls' in other user's home directories, mail stores, or web files.
apache, procmail, dovecot et cetera, are in the appropriate groups and therefore have access needed to do file ops. however, they're limited to their appropriate stores.
as mentioned at the beginning, dovecot tries to match the gid of the parent directory for new files and normally, that's desired and expected behavior, but in our case. dovecot creates the file as uid/gid of the user, so the knob can either ignore the failure to set gid per the parent and not log it, or not attempt to set the gid per parent in the first place.
src/lib-storage/index/maildir/maildir-uidlist.c 1412: if (box->file_create_gid != (gid_t)-1 && fchown(fd, (uid_t)-1, box->file_create_gid) < 0) { if (errno == EPERM) { mail_storage_set_critical(box->storage, "%s", eperm_error_get_chgrp("fchown", temp_path, box->file_create_gid, box->file_create_gid_origin)); } else { mail_storage_set_critical(box->storage, "fchown(%s) failed: %m", temp_path); } }
to something like: ( "new_files_inherit_parent_gid = true" )
if (box->file_create_gid != -1 &&--> box->new_files_inherit_parent_gid) { fchown(fd, -1, box->file_create_gid) ... }
bool new_files_inherit_parent_gid [default true] could be added the following for example: src/lib-storage/mailbox-list-private.h:struct mailbox_list src/lib-storage/mail-storage-private.h:struct mailbox
this block of code appears in similar instances for a number of other occasions (and could be made a more global function), but not all files in ~/.maildir/* appear to use a function like this. the uidvalidity functions are a little different for example.
==
for a busy mail server, that's a lot of excess logging and pollution when trying to review nightly logs for issues :)
thank you for the consideration, -david
What if you create the topmost mail directory (and everyting below) with setgid set (or use BSD mkdir semantics)?
On 5.10.2010, at 20.13, David Ford wrote:
drwxr-x--- david net-mail /home/david/.maildir drwx------ david david /home/david/.maildir/cur
Can you give me some use case for what the net-mail is used for?
to something like: ( "new_files_inherit_parent_gid = true" )
I hate settings that are going to be used only by about one installation. Maybe there's another way.
net-mail group is used by sendmail, procmail, dovecot, and additional programs that read/write in the users mail directory. without permissions such as below and using typical permissions, other users can cd into a users .maildir and identify all folders a user is subscribed to (personal information leakage), watch for new emails (timing attacks). the same goes for the web directories. the source of web scripts can be revealed as well as other information.
our users tend to be picky about security and privacy amongst themselves, and it's not always possible to make each daemon set their id or group id to the user or not be noisy about unexpected lack of permissions when doing file operations for the user. each service has their own idea about how file permissions should be set.
daemons not in the net-all group simply don't have access to the user's home directory regardless.
the "other way" is having dovecot not attempt to emulate the setgid bit of a directory and fchown() children in that directory, . dovecot would then simply set the uid/gid of the file as the user it's currently running as. if users want to force files created in that directory to a given gid, they could set the gid and chmod g+s on that directory.
On 10/05/2010 06:17 PM, Timo Sirainen wrote:
On 5.10.2010, at 20.13, David Ford wrote:
drwxr-x--- david net-mail /home/david/.maildir drwx------ david david /home/david/.maildir/cur Can you give me some use case for what the net-mail is used for?
to something like: ( "new_files_inherit_parent_gid = true" ) I hate settings that are going to be used only by about one installation. Maybe there's another way.
On 5.10.2010, at 23.38, David Ford wrote:
net-mail group is used by sendmail, procmail, dovecot, and additional programs that read/write in the users mail directory.
Can you give some specific examples?
drwxr-x--- david net-mail /home/david/.maildir drwx------ david david /home/david/.maildir/cur
Does new/ and tmp/ directories then have netmail-rx so mails can be delivered? What about non-INBOX mailboxes? Or what exactly is the point of not just making .maildir/ 0700? Or if new/ dir is g+rw, is it important that cur/ directory isn't?
On 10/05/2010 06:44 PM, Timo Sirainen wrote:
On 5.10.2010, at 23.38, David Ford wrote:
net-mail group is used by sendmail, procmail, dovecot, and additional programs that read/write in the users mail directory. Can you give some specific examples?
i did. sendmail accesses .forward or aliasing files, procmail does delivery, dovecot does read/write for imap, pine reads and writes and webmail cgi reads and writes or uses imap.
drwxr-x--- david net-mail /home/david/.maildir drwx------ david david /home/david/.maildir/cur Does new/ and tmp/ directories then have netmail-rx so mails can be delivered? What about non-INBOX mailboxes? Or what exactly is the point of not just making .maildir/ 0700? Or if new/ dir is g+rw, is it important that cur/ directory isn't?
new/ and tmp/ are set to david:david 0700 as cur/ is, as well as all non-INBOX. .maildir cannot be 0700 because programs that don't run as the same userid but only as the group id cannot then access the .maildir directory. it's not important that they have access to files below the top level mail store. procmail issues an error when writing in tmp/ as well.
~/.maildir/ is not setgid because i don't want files forced to the net-mail group. dovecot is taking it upon itself to do so anyway. that's nice and all, but not desired and the directory permissions aren't set for this policy. to be technical, it's unexpected. i want my email files to be set to david:david, not david:other-group. dovecot should not assume that the gid should be set differently from my user's gid.
the group permissions are set for read/exec in this directory for this group, the minimum needed for all the daemons to play nicely with each other, and with the user.
On 6.10.2010, at 0.09, David Ford wrote:
On 10/05/2010 06:44 PM, Timo Sirainen wrote:
On 5.10.2010, at 23.38, David Ford wrote:
net-mail group is used by sendmail, procmail, dovecot, and additional programs that read/write in the users mail directory. Can you give some specific examples?
i did. sendmail accesses .forward or aliasing files,
Isn't .forward typically in home dir, not under maildir? I don't know about per-user aliases file (there's such a thing?), but I'd guess that is also under home dir.
procmail does delivery, .. new/ and tmp/ are set to david:david 0700 as cur/ is
It can't do delivery as net-mail group if they're 0700.
dovecot does read/write for imap, pine reads and writes and webmail cgi reads and writes or uses imap.
None of those can work either with net-mail group permissions since all the necessary dirs are 0700.
.maildir cannot be 0700 because programs that don't run as the same userid but only as the group id cannot then access the .maildir directory. it's not important that they have access to files below the top level mail store. procmail issues an error when writing in tmp/ as well.
You still haven't given one example of where it's actually useful to have it 0770. Seems to me that your problem would simply go away with chmod 0700 .maildir.
On 10/05/2010 07:17 PM, Timo Sirainen wrote:
It can't do delivery as net-mail group if they're 0700.
dovecot runs as my userid; david:david so it has permissions for accessing anything in .maildir/ and below. this is why it gets EPERM errors when it tries to set the group id of net-mail.
it's a bug in dovecot to assume a) the user wants this gid change even without setgid, and b) that it can change the gid to an arbitrary value of a parent directory.
other software runs as <something>:net-mail, and it's use and operation is not applicable to this discussion. mode 0700 is not functional for this group of software and mode 0770 is too lax.
On 6.10.2010, at 0.26, David Ford wrote:
it's a bug in dovecot to assume a) the user wants this gid change even without setgid, and b) that it can change the gid to an arbitrary value of a parent directory.
other software runs as <something>:net-mail, and it's use and operation is not applicable to this discussion. mode 0700 is not functional for this group of software and mode 0770 is too lax.
Your situation seems like a very special case that probably doesn't exist just about anywhere else. Unless someone can give me a specific use case for this that can't be solved nicely some other way, I'm not changing Dovecot's behavior.
On 10/05/2010 07:35 PM, Timo Sirainen wrote:
On 6.10.2010, at 0.26, David Ford wrote:
it's a bug in dovecot to assume a) the user wants this gid change even without setgid, and b) that it can change the gid to an arbitrary value of a parent directory.
other software runs as <something>:net-mail, and it's use and operation is not applicable to this discussion. mode 0700 is not functional for this group of software and mode 0770 is too lax. Your situation seems like a very special case that probably doesn't exist just about anywhere else. Unless someone can give me a specific use case for this that can't be solved nicely some other way, I'm not changing Dovecot's behavior.
what is the purpose in dovecot assuming that it should set a gid other than the userid:gid it's operating under?
security minded folks make explicit permissions on directories to prevent software from errantly setting loose ownership which might lead to unintended information leakage or unauthorized access by other software. the directory is not setgid, programs should not attempt to give away ownership unless directed to.
consider /tmp. it would be onerous to write files in /tmp and attempt to set the group ownership to root. currently, about 40% of the files and directories under /var are set to <x>:<x> where /var is owned by root:root.
it's simply bad practice to give away ownership unless there is a reason for it, and a common vector for exploitation.
On 6.10.2010, at 0.56, David Ford wrote:
what is the purpose in dovecot assuming that it should set a gid other than the userid:gid it's operating under?
Shared mailboxes.
security minded folks make explicit permissions on directories to prevent software from errantly setting loose ownership which might lead to unintended information leakage or unauthorized access by other software. the directory is not setgid, programs should not attempt to give away ownership unless directed to.
Maybe it should have been done only with g+s mode set. I may have had a reason for why I didn't do it that way, or maybe not. Changing it now would anyway break existing installations, so that doesn't seem like a great idea either.
participants (3)
-
David Ford
-
Edgar Fuß
-
Timo Sirainen