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 == [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.
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 -- ## 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/
