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 == myuser@??? 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.
