develooper Front page | perl.perl5.porters | Postings from September 2011

Re: [perl #98934] set{u,g}id doesn't clear $! on success

Thread Previous | Thread Next
Chris Adams
September 14, 2011 02:07
Re: [perl #98934] set{u,g}id doesn't clear $! on success
Message ID:
Once upon a time, Leon Timmermans <> said:
> On Mon, Sep 12, 2011 at 9:50 PM, Chris Adams <> wrote:
> > The problem is that is not what the documentation says.  The docs say
> > "require a check to $! to detect any possible errors", not "you must
> > clear $! first, make your change, then check the results".
> Then the documentation should be clarified.

Can you name any other part of core perl where you have to manually
reset $! yourself?  Why should the set{u,g}id changes be special?

> > The underlying problem is that the perl source code doesn't check or
> > save the return code from the setregid() call.  Since library calls can
> > have unexpected side-effects, perl should handle this internally.
> It's an abstraction that leaks like a sieve. If you ask me the obvious
> way to deal with this would be to throw an exception on error, but
> that will probably require a «use 5.016;». Using a module that does
> the right dance still sounds like a better idea though.

Using a module to paper over a deficiency in the core language is rather

> > This is highly confusing, and there's really no reason to push this off
> > on the people writing perl code.  At a minimum, perl internally could do
> > something like:
> >
> >    if (setregid(gid,-1) == 0)
> >        errno = 0;
> >
> > (and that goes for all the setuid/setgid family of functions).
> That might piss off an equal number of users because $! gets
> overwritten when they didn't expect it.

Anybody depending on $! to _not_ change is going against the
documentation already (since the assignment is documented to affect $!).

> > No, I only want to set the real GID here (I'm dropping privs temporarily
> > for a check).
> Please explain yourself. What does setting the real GID do for you? It
> has very little to do with dropping any privileges, temporarily or
> permanently.

Please stop trying to critique code you have not seen and have no idea
what it is doing.  Here's a hint: access() (and no, it isn't always a
race condition).

Chris Adams <>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About