Jason Keltz wrote:
> 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.
Not without 'bounds'.
As you've specified /some/path/plus/$local_part
Just what part of that could they change?
And where and how would they enter/convey their wishes?
I think you are looking at the wrong end of the problem.
> If I was using the "group = mail" but didn't have allow_symlink set, can
> this still work? or no?
>
Aside from shell account holders, who may or may not have various levels
of fs access and/or perms to invoke the 'exim' binary, Exim does not
interact with users. It interacts with 'message traffic'. smtp and
non-smtp sessions/injection.
The Exim *daemon* transfers messages according to the rules the admin
gave it. It either has a valid address Exim can route - or not.
To the extent those rules have a mailstore structure hard-coded,
looked-up from file, or 'built' on-the-fly by some combination of
hard-code, variables, or even (our case) SQL selects, these are ALL
beyond the effective control of the user.
Not to forget, there can be a finite, but very large number of options
based on routers, but all are still under the control of the configure
file, not interactive user input.
IOW - at no point does Exim stop and ask:
'By the by, you want this message stored in the usual place, or would
you like to specify something kinkier?'
So - given reasonable routers - it isn't Exim you need to worry about -
it is your POP (doubtful) IMAP or Web-mail service - (likely), as these
ordinarily can be told where to seek the storage, and can ordinarily
write to it to create indices and folders.
These are the places where you need to insure a user - or the service he
is (ab)using, cannot get out of his box, browse messages not his own,
or create a problematic fs structure.
Even so, it is a function of secure ID & auth. Directory structure &
perms are important - but ordinarily either fully static, AND/OR/ELSE
limited in degrees of freedom (downward, but not across or upward).
Back to Exim - AFAIK, it does NOT need 'allow_symlink' to follow or use
symlinks if/as/when created by others - the underlying fs handles that
transparently. 'ls' vs 'ls -lF' shows trhe difference.
If you research it (I have not) I suspect you will find that
'allow_symlink' is only to let Exim *create* symlinks if/as/when needed.
(Likewsie, Dovecot has an option to use 'hardlinks' - or not - for
multiple delivery & multi-copy storage).
But Exim ordinarily does NOT need to create symlinks for storage - even
in the 'migration' case you cite, as it can either work directly with
'the truth' while POP/IMAP are given an alias, OR use a symlink created
by some other process ahead of time, and just hang the per-user
mailstore under that as it would any other dirtree.
Much the same as a mount-point. You just tell it where to start.
So I don't think you need this setting at all.
Even if the structure is to be populated on-the-fly, you can put the
higher-level symlink(s) into place manually beforehand. Router/transport
sets do the rest.
*snip* (/var/mail storage issue)
Bill
