Skip Menu |
 

This queue is for tickets about the Gantry CPAN distribution.

Report information
The Basics
Id: 39608
Status: new
Priority: 0/
Queue: Gantry

People
Owner: Nobody in particular
Requestors: jarich [...] perltraining.com.au
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 3.53
Fixed in: (no value)



Subject: Gantry 3.53 Build.PL subject to race condition
Download (untitled) / with headers
text/plain 954b
On line 199 of Build.PL the code attempts to change the permissions on a file (which may not exist - as per my previous bug #39607 regarding Build.PL's failure to honour destdir) to be world writable. Assuming success, the code then goes on to clobber that file, rewrite it and then reset the permissions. By setting the file to be world writable, there is the risk that after the write, but before the permissions are reset, that any other process could edit, truncate or otherwise interfere with that file. Since the user running the code has the rights to change the permissions of that file, it seems likely that they could already write to that file. If this is not the case, because the read permission has already been removed by earlier code, then surely all one needs to do is give that user write permission? Not everyone? I suspect it would be better, if this is required to use the permissions octal: 0644 instead. Thanks, Jacinta


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.