bugMHonArc - Bugs: bug #13853, creation of archive with...


You are not allowed to post comments on this tracker with your current authentication level.

bug #13853: creation of archive with attachments writes over symlinks

Submitted by:  None
Submitted on:  Wed 20 Jul 2005 01:14:33 AM UTC  
Category:  MIME Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Undesired Behavior
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  Linux Perl Version:  5.8.1
Component Version:  2.6.11 Fixed Release:  2.6.17

( Jump to the original submission)

Fri 31 Dec 2010 08:37:09 PM UTC, comment #8: 

I added FOLLOWSYMLINKS resource.  If enabled, symlinks will be

The resource is DISABLED by default to maintain capability
with previous behavior.

Earl Hood <ehood>
Project Administrator
Mon 30 Jul 2007 02:59:55 AM UTC, comment #7: 

>1 Add a FOLLOWSYMLINKS resource that tells mhonarc to leave
>symlinks alone. This would have to be explicitly enabled.

Maybe go with whatever sounds easiest, and that's probably
this one. I keep my mhonarc patched to essentially do this,
and every so often get myself in trouble when I forget to
forward port the patch between mhonarc releases.

Jeff Breidenbach <jab>
Sun 25 Dec 2005 02:05:07 AM UTC, comment #6: 

I'm not sure checks #2 and #3 actually buy anything more than what is already available with unix file permission, and may be more trouble than benefit. If the filesystem says it's ok to write, that that's probably good enough.

So just #1 is fine with me. I could even imagine it being turned on by default since it's not like mhonarc would be following symlinks in /tmp. And lots of basic unix utilities have no problems following symlinks. Maybe there is some scenario that I'm not considering - off by default is also ok now that I know about the problem.

By the way, the use case I'm thinking about is when reiserfs starts corrupting itself and I don't want to spend a week running reiserfsck. Easier to move the various mhonarc archives one at a time to a new filesystem, which also takes a week. But one can patching the whole thing together with symlink duct tape during the process - keeping the system live and the problems invisible to the user. I can easily imagine doing this process again (sigh) sometime over the next few months.

Jeff Breidenbach <jab>
Tue 20 Dec 2005 08:51:23 PM UTC, comment #5: 

Possible fixes that can be applied:

1 Add a FOLLOWSYMLINKS resource that tells mhonarc to leave
  symlinks alone.  This would have to be explicitly enabled.

2 Check the user ID of the symlink to see if it matches the
  pid of the mhonarc process.  If so leave symlink alone.

3 Along with the previous check, check if the symlink uid
  matches the uid of the containing directory.  If they match,
  leave it alone.  With the previous check, both would have
  to pass to leave the symlink alone.

(2) and (3) may be sufficient for security reasons and avoid
the need for FOLLOWSYMLINKS, except for certain use cases.
I.e. All of the above can be done, with (2) and (3) added as
the default and (1) only done when explicitly enabled.  (1)
would bypass any ID checks.


Earl Hood <ehood>
Project Administrator
Sat 10 Dec 2005 04:40:34 PM UTC, comment #4: 

I stumbled on the same problem with the symlink error msg, when
I installed V 2.6.15.
I keep archives in yearly directories and there is a symlink
current -> 2005.
The archiver, invoked from mailman, is

PRIVATE_EXTERNAL_ARCHIVER = "/usr/local/bin/mhonarc -add -outdir /www/mailman/archives/private/%(listname)s/current >> /tmp/mhonarc-mc.log"

in this way, at midnight, new year's day, all I have to do is switch the symlink around, no messing with mailman configs or editing an alias file. As I understand, this alone would be OK,  but by default the outdir is also the attachmentdir, and this is where mhonarc trips over the symlink (BTW: while it might be ok to print the error and exit, I don't think is ok to try to delete the symlink). I did not see this problem with existing archives, which I did not recreate after switching to 2.6.15, but with any archives that I redid after the update.

One might try to define a relative AttachmentDir to solve the problem.


but this does not work, as was noted in the mhonarc-user mailing list
(http://www.mhonarc.org/archive/html/mhonarc-users/2005-01/msg00004.html). with the mhonarc invoked as above, the attachments directory is created in the processes' working directory, which is mailman's home directory, /www/mailman. It is not created in the outdir and any existing one there is not used.


Wed 24 Aug 2005 12:56:40 AM UTC, comment #3: 

>The symlink check is done to prevent local symlink attacks.

>Somebody else recently reported a problem with mhonarc's behavior:

Please post a follow-up to the report providing specifics of your
case.  Also provide any diagnostic messages mhonarc produces
(for symlink stuff, mhonarc should generate a warning or error).

I see the "is a symlink, will try to replace..." message.

>The problem is only if the final pathname component is a symlink.

A work-around is to not have the attachment directory be a symlink.

>If I understand your problem correctly, I am guessing that you

have attachments being placed in the same location as the archive
directory.  And the archive directory is actually a symlink?

The archive directory is a symlink. Attachments are supposed to be placed in a subdir, underneath the archive directory. I have not 100% verified that this is what is happening, but have anecdotal evidence that makes me 85% confident.

==== originally sent to mhonarc-users ====

Recently a colleague and I were doing some filespace juggling and
moved some mhonarc archives around. Specifically, we moved an archive
to a new parition and then made a symlink at the old location.  That
didn't go so well.

Most messages archived fine, then we hit one that had an attachment
and tried to create a directory to put the attachment in. Well, that
triggered some unusual code in mhfile.pl that decided to delete the
symlink, create an empty directory, then mhonarc got confused as to
why all the message pages had disappeared. Everything went downhill
from there.

I'm not sure what intention of this code is, but at least for me it's
kind of dangerous and we were lucky to catch the issue right away.
We've commented out the portion of code, and seem to be ok. But maybe
it is something worth revisiting for the next mhonarc release.



   ## Check if $path is a symlink
   if (-l $path) {
       # symlink, try to delete
       warn qq/Warning: "$path" is a symlink, will try to replace...\n/;
       if (!unlink($path)) {
           die qq/ERROR: "$path" is a symlink, unable to remove: $!\n/;
   } elsif (-e $path) {
       die qq/ERROR: "$path" is not a directory: $!\n/  if !(-d _);
       # already exists, nothing to do

Jeff Breidenbach <jab>
Wed 20 Jul 2005 02:51:38 AM UTC, comment #2: 

yep, submitted anon.. sneaky me!
(but I am watching the thread :)

We are testing your suggestion.

Will let you know..

Wed 20 Jul 2005 02:00:34 AM UTC, comment #1: 

It will help if you provided more context on why
you want to preserve symlinks, mainly, how they
are exactly being used.

I am guessing you are using the subdir option to
the m2h_external::filter, or using the ATTACHMENTDIR
option.  Is this correct?  (since you submitted anon,
you may never see my questions, sigh.)

The symlink check is a security precaution to prevent
local redirection, or overwriting, of files.

If using the ATTACHMENTDIR resource, you can work-around
the problem by not having the base part a symlink, but
the parent one.  For example, if ATTACHMENTDIR is


/my/path/to is a symlink to the filesytem you desire,
and "attachments" is a physical directory.

Earl Hood <ehood>
Project Administrator
Wed 20 Jul 2005 01:14:33 AM UTC, original submission:  

We use a symlink farm to house the on-disk archive state for local
reasons (v's real directories)

when a email with an attachment is received, the symlink is destroyed
and a directory recreated in its place. (as that is what dir_create does!)

in sub write_attachment (file mhmimetypes.pl) an unchecked call
to dir_create is made.

As a workaround I have conditionalised the use of dir_create as follows.

## check to see if the  symlink is already there! - tjm
    if ( !(-l $pathname) )

While you obviously see the deletion of symlinks as a feature, I see it as
a bug. Perhaps you could add a configuration flag that will allow people
to selectively disable the symlink removal behaviour?



No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ehood (Updated the item)
  • -email is unavailable- added by jab (Posted a comment)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-01-09 ehood Open/ClosedOpen => Closed
    2011-01-09 ehood StatusReady For Test => Fixed
        Fixed Release => 2.6.17
    2010-12-31 ehood StatusIn Progress => Ready For Test
    2010-12-31 ehood StatusNeed Info => In Progress
    2005-07-20 ehood Severity3 - Normal => 1 - Wish
        StatusNone => Need Info

    Back to the top

    Powered by Savane 3.5