Re: [exim] appendfile allow_symlink

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.