My original post said that the program is setgid, not setuid. For slightly more context, the application in this case is a shell-like interpreter that is sgid so it can read/write data out of a common file shared by other users of the app. It happens to let you run shell commands, but (and here's where I'm uncertain), it doesn't setgid back to your real gid when it forks. I'll have to look into why this is the case. But, that aside for the moment:

The real issue for me is perl's decision about what to protect. It's true that if I'm opening a file that's owned by ME, even if taint is on, then perl doesn't complain. However, if I open a symlink to exactly that same file (even if the symlink is owned by someone else), I would say that it *still* shouldn't complain... but it does, leaving me with no possible way to open that file for writing. I may not know (or even care) what that symlink points to, if I say "open '>filename'" I want it to open, truncate and return me a filehandle, so long as the OS gives its blessing.

If I had a handle to the file, I could call FH->untaint(), but I can't get a handle because perl won't let me open it for writing in the first place. I realize I could examine the file to see if it's a symlink, follow to where it goes, and then do the open call, but frankly, that's what perl should be doing before it decides to bar me from having access.

What mechanism do I have at my disposal? And more importantly, what mechanisms does perl provide to anyone using similar conditions? Please don't suggest having a wrapper application that resets my gid, because that won't address potentially more complicated perl apps and modules that may not have that option. I'd like to see a perl-based programmatic api for dealing with this sort of thing. I think it'd be best to just have a new form of "no taint"-type of option with appropriate params that doesn't cause previously documented behaviors to break. I'd even accept a new param for sysopen() to get around this.

I don't want to dismiss how nice it is for perl to keep you from hurting yourself when using the basic, straight-up simple API of perl, but having very specific mechanisms to get around such protections is also part of the spirit of perl.