Front page | perl.perl5.porters |
Postings from September 2011
Once upon a time, Leon Timmermans <fawaka@gmail.com> said:
> On Mon, Sep 12, 2011 at 9:50 PM, Chris Adams <cmadams@hiwaay.net> 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
backwards.
> > 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 <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Thread Previous
|
Thread Next