Front page | perl.perl5.porters |
Postings from January 2009
On Mon, Jan 26, 2009 at 1:31 PM, Abigail <abigail@abigail.be> wrote: > On Sat, Jan 24, 2009 at 11:11:08PM -0500, Charles Bailey wrote: >> >> - Moves the permission-changing code to File::Copy::cp(), making it >> non-identical to File::Copy::copy(). I think this is a decent >> compromise, retaining backwards compatibility in the "primary" >> routine, while allowing people who chose cp() to get more POSIXy >> semantics. It does break backwards compatibility of cp() wrt >> permissions. I can find a handful of examples in CPAN, for which I >> hope smokers will give some feedback. As for the DARKpan, who knows . >> . . > > > Basically, 'cp' is now 'copy', then, afterwards, setting the permissions > (if the file is new). This opens the possibility for a race. Imagine > having a file with sensitive data. Permissions of the file are 0600. Now, > if you copy it using cp, and your umask is '022' (not uncommon), there's > a brief moment the copied file will be readable by all (permission 0644). > > This wouldn't happen if the new file was opened using sysopen() with the > appropriate permission (which is what the IEEE 1002.1 standard says > it should do). I'm not sure File::Copy aspires to this level of security. But perhaps the best of both worlds would be to look at $to in F::C::cp(), and if it's not a handle, require Fcntl and sysopen a handle with the permissions we just figured out, then pass it to copy(). If the caller passed in a handle, we can't do this, but the standard says permissions on existing files won't be changed anyhow (excepting set[gu]id bits). Then just make sure everything in the Perl build uses copy() and not cp(), and we won't have to worry about availability of Fcntl. -- Regards, Charles Bailey Lists: bailey _dot_ charles _at_ gmail _dot_ com Other: bailey _at_ newman _dot_ upenn _dot_ eduThread Previous | Thread Next