On 03/28/08 14:06, W B Hacker wrote: > Jason Keltz wrote: >> On 03/28/08 12:01, W B Hacker wrote: >>> Jason Keltz wrote: >>>> By default, appendfile will not deliver if the path name for the file >>>> is that of a symbolic link. Setting the allow_symlink option relaxes >>>> that constraint. Is there any way that I can get middle ground by >>>> enabling "allow_symlink", but only allowing symlinks that are owned >>>> by say, root/exim? I don't want a user to be able to delete my >>>> symlink of /var/mail/USER to /real/path/of/var/mail. >>> As it is the path - not the file at the end of it - you wish to deny >>> user modification of, I'm not sure what *n*x perms cannot already >>> protect.. >> I don't mind if the user erases the file at the end of the path. I just >> want /var/mail/USER to always point to a particular file. >> >>> That said, I don't see what the advantage is of using a symlink in the >>> first place. >>> >>> Userland need not have 'visibility' of the whole dirtree, let alone >>> perms to modify it - only the Maildir or Mbox at the end of it. The >>> POP/IMAP needs the whole shebang (as Exim does), but need not expose >>> it to the user. >>> >>> That said, none of our shell accounts have mail, and all of our mail >>> accounts, paths, privs, and mailstore are 'virtual' - even the >>> postmaster@, so my practice may not fit your environment. >> In our case, all of our machines have access to /var/mail via NFS for >> local mail applications that do not use imap/pop. We will start to >> change this soon by small groups of users at a time. However, in order >> to be able to do this, we would like to be able to place the mail of the >> "localized" users into a different directory on the mail server, and >> then symlink /var/mail/USER to say, /local/mail/USER .. Now, the users >> can only get at their INBOX via imap, yet exim can still deliver to >> their inbox because its still writing to /var/mail. Later once everyone >> has been moved, /var/mail will simply become /local/mail. If there was >> an "allow_root_symlink" instead of just "allow_symlink", this would >> solve my problem. >> >> >> Jason. >> > > I still see that as a 'non-Exim' issue. > > Real-world example (un-line-wrap this): > > ========= > > lrwxr-xr-x 1 root mail 40 Feb 2 2007 .ALLRECD@ -> > /data/mail/archive/<domain>.<tld>/Maildir/.Recdall > > lrwxr-xr-x 1 root mail 48 Dec 28 16:05 .ALLSENT@ -> > /data/mail/archive/<domain>.<tld>/Maildir/.Sentall > > ========= > > The above symlinks are a key part of a structure that allows corporate > oversight, via IMAP folders in a 'Management' account, of all traffic in > and out from all staff of a given <domain>.<tld>, even if the staff > member has deleted the message (archives are not available to ordinary > users). > > The *symlink* ownership and perms prevent either Exim or IMAP from > altering them, though as members of group 'mail' they can > traverse/search/follow them. The 'x' bit sees to that for dirtrees. > > The Maildirs at the end of these could have 'ordinary' ownership, NOT > owned by root (though the example does not have such, as this is a a > read-only tool) - only the symlinks to them are critical. > > Looks similar to your need in that all you need to do is use the > Unix/Linux tools chown & chmod on the symlinks to set ownership and > privs that prevent users from altering them but allow Exim and family to > traverse them as needed. > > Exim has no issue so long as it is in the same group - 'mail', above - > so worst-case, you may gave to alter group memberships in /etc/group et > al. Membership for this purpose need not be identical to whatever you > use for the Maildir/Mbox at the end of the path, nor identical to the > new structure you are migrating to.
This is exactly what I want to be able to do, but it's not working because every time I try to send a message to an account, I get: 2008-03-28 15:34:42 1JfKLa-0001ev-OA == [EMAIL PROTECTED] R=localuser T=local_delivery defer (-6): mailbox /var/mail/myuser (symlink) has wrong uid (0 != 1234) My local_delivery is: local_delivery: driver = appendfile transport_filter = /xsys/bin/spamc -U /tmp/spamd.sock file = /var/mail/$local_part delivery_date_add envelope_to_add return_path_add headers_remove = X-UID:X-IMAPbase:X-IMAP # group = mail # mode = 0660 I don't want to add "allow_symlink = true" because now users would be able to create their own symlink as well where I haven't created one. If I was using the "group = mail" but didn't have allow_symlink set, can this still work? or no? > Side issue, you mention using the classical /var/mail for storage. > > Note that the above mailstore does NOT sit under '/var', as /var is a > general-purpose mount-point that must care for many needful things, can > get filled by runaway logs in /var/log, a full print spooler, et al - or > even get clobbered entirely if you install a new OS. > > Our mailstore is ordinarily kept entirely separate from any 'system' > mounts - a separate RAID1 array here. Further, the 'working' and > 'archive' sets can be on separate RAID1 arrays. Yes... We use raid for our mail, and bind mount to /var/mail. Jason. -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
