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.
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.
Belt, braces.... and kevlar..
;-)
HTH,
Bill
