Anyway, here's some new info that obviously answers the question, although I'm not sure why... leading me to think there's either a design error, or a bug.
Turns out, the file I'm writing to is a symlink owned by root, but it points to one of my files owned by me. I wasn't aware of this till now, and is probably the result of a system restore that was recently done due to a failed hard drive. (The symlink was always there, and used to be owned by me before the crash, but it must have gotten the root ownership when it was restored.)
It's clear that perl is noticing that the file isn't owned by me, and is preventing me from opening it without even trying. I did the right thing--I changed my gid back to my own, but perl still insists on not even attempting to open it. Why not, at this point, just defer to the OS and let open succeed or fail accordingly. Why should perl attempt to to play God (above the OS), especially if I'm trying to tell it not to. Not only did I NOT use -T, but I'm also trying my best to satisfy perl by setting my uid and gid to ME. What more do the designers of perl expect of me? If perl is going to play nazi above the OS, at least be smart about it and look to see if the final destination file is owned by me.
In reply to Re^2: Insecure dependency in open
by argv
in thread Insecure dependency in open
by argv
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |