You have obviously read the perldiag section:

The tainting mechanism is turned on when you're running setuid or setgid, or when you specify -T to turn it on explicitly.

However I don't think you understood the timing. When perl starts it notices the mismatch in uid/gid values and at that point turns on taint mode. And barring magic, taint mode stays on from the start of the program onwards. You can't turn off taint mode just by un-mismatching the uid/gid values.

Start a perl program in setuid mode and you get taint mode for free. You didn't have to ask for it, but perl wants to protect you from yourself. This only sank in the most recent time I did it to myself. So then I went off and did the untainting manipulations needed to 'clean' the data, because the program _might_ be run in taint mode, depending on the conditions when starting it.

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.

Dan Heller
http://www.danheller.com

Easiest way to fix that symlink stuff is

$file = readlink($file) if -l $file;
[download]

Don't fight your tools.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I see my "reputation" points are going into the negative whenever I reply to postings with mere reports that the advice I'm being given isn't working. Am I doing something anti-social? :-)

Of course not, since what you write has nothing to do with social issues. And it's not your reputation that decreases, but the node's, even if that might involve loss of XP to you (which really isn't diminishing your reputation either :-).It's a sad fact that downvotes generally aren't accompanied by an explanation. I would like to see stated within the monastery guidelines that downvoting should be accompanied by a node or a private /msg to the author of the downvoted node, whenever possible.

It lies in the nature of approval and dissent, that approval is rarely questioned, but dissent is. If downvoting is a corrective, and meant to incite the poster of the downvoted node to rethink the contents of their post, I deem it a good practice to give the OP a hint of what is deeemed wrong with their post.

Back to the issue at hand: the overall picture is still not clear to me. You have a setuid binary that allows you to invoke perl with some file as argument. What beast is that binary? is it some shell? what permission bits are set for that binary, what bits are set for the perl file, or the link that points to it? what's in the perl script being invoked? What OS do you have, which perl version?

I can't reproduce the problem with the information at hand. Or maybe I'm just not trying hard enough.

--shmem

update: strike through

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

And it's not your reputation that decreases, but the node's, even if that might involve loss of XP to you (which really isn't diminishing your reputation either :-)

Not that this matters much here, but I was just kidding... however, had I known some of the deeper perlmonks issues at hand (about downvoting), I wouldn't have been so quick to jest. I agree with your proposal that the guidelines should indicate a private message to the poster to indicate what's wrong with the post, but I'll leave this issue to the saints who run the place. It's beyond my domain.

Dan Heller
http://www.danheller.com