in reply to RE: lock files vs. non-predictable file names
in thread lock files vs. non-predictable file names

This code scares me a bit:
my $oct_mode = sprintf "%lo", $dec_mode; if (-O $private_dir and ($oct_mode == 40700)) { return } elsif (-O $private_dir and ($oct_mode != 40700)) {
You are probably lucky that 40,700 decimal is a nice integer value. Why not leave it at octal?
if (-O $private_dir and ($dec_mode == 040700)) { return } elsif (-O $private_dir) {
And that value isn't really a "decimal" mode. It's the value of "the mode", which usually prints out as decimal. Internally, it's binary, unless you have a BCD-coded machine (not likely {grin}).

The other scary code here is your use of mailx. While the content of your message cannot possibly contain a line that begins with tilde, you might get complacent some day and permit such a line, and then you can say buh-bye to security. Get in the right groove by looking at Mail::Mailer pretty durn quick.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: RE: lock files vs. non-predictable file names
by RuphSkunk (Acolyte) on Aug 28, 2000 at 21:35 UTC
    So, what you are trying to say is that perl stores the value that stat returns as a binary, but when I printed it out perl converted it to decimal. OK I think I got that now, but this other bit of code you left, I'm not sure I fully understand. Is that leading character a zero in 040700 and if so what does it do? presumably it causes an octal comparison? I guess where I got the code I came up with was by
    mkdir($private_dir, 0700); $mode = (stat($private_dir))[2]; print "stat[2] returned $mode for a value\n"
    the value returned was 16832 which clearly wasn't an octal value. Could you explain to me a little bit about arbitrary base comparisons? I can't find any examples that I recognise. Also thank you for the bit o' wisdom on mailx, I didn't know it had that vunerability(sp).
      Perl stores the value as a "number". This could be binary, or hex, or bcd, or whatever. Interpolation of that value causes it to be rendered in decimal, yes, and that's why you don't recognize it, because you aren't RainMan and can't convert from decimal to "bits" in your head. {grin}

      The leading 0 in 040700 tells Perl to accept this number in octal (again, easier to encode bits as a human that way), but once accepted, it's again a "number", and can be compared with other "numbers".

      -- Randal L. Schwartz, Perl hacker