Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=751886 --- Comment #3 from Tomas Hoger <thoger@xxxxxxxxxx> 2011-11-10 04:17:49 EST --- I gave this some look yesterday, and I can't see any nice way to fix this either. Safely creating temporary directory under /tmp would probably be the least invasive way to fix, but there's a problem with the clean-up at the end. It seems it's valid to use this module in a way that parent process forks bunch of child processes, let them do their work and exit before they finish. Hence this approach should leave a temporary directory behind on each run of such script. Changing child code to create the file safely does not seem like an option either. If the predictable file name is used, attacker may "DoS" the child (create temp file so that child can not while its "reply" data structure). Child can block (keep re-trying to create the file) or exit (let parent parse malicious file), but cases seem wrong. As a side note, in current implementation, parent process tries to read the temp file even when the script is not written to use this data passing feature. Hence attacker can easily make parent deserialize arbitrary malicious Storable blob. Storable man page only mention it's unsafe when storing / retrieving of CODE is allowed (not by default), but still sounds like "don't do this". Even if it's safe, that may have other side effects (block parent on read, make it use extra memory, trigger side effects when opening special files). Parent process can create temp file safely, but can not use predictable file name with its current format, as it does not know child pid before fork. Hence it'd need to use random name and have it stored in both parent and child data structs. Of course, this has the same problem as temp dir idea in cases where parent exits before child. One improvement can be to create temp file only when script wants to use structure passing (and hence parent is expected to wait for child), i.e. when on_finish callback is set. However, even though docs say to declare callbacks before first start, it's apparent you can set them after start, as run_on_finish accepts optional pid argument to set child-specific callback. I'm not sure what the intended semantic was, as setting callback after run is racy and the callback may not be run if child exits quickly. One idea is to make new's tempdir parameter mandatory if script wants to use structure passing, and document that caller should provide a safe temporary directory (i.e. not /tmp) - such as directory that is not world writeable (/home/user/something or /var/lib/something), or safely created under /tmp. Of course, that's something that we can't do without upstream. We can downgrade module to the F14 version that lacks this new feature ;). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
