develooper Front page | perl.perl5.porters | Postings from December 2017

Re: [perl #104060] Writing to $> and friends hide errors

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
December 13, 2017 01:26
Subject:
Re: [perl #104060] Writing to $> and friends hide errors
Message ID:
CAHhgV8jpWxbRnL21aykQw7oKxqqxF1LZaRUb8XGBy8sGEj4_Ng@mail.gmail.com
On Mon, Dec 11, 2017 at 7:24 AM, Zefram <zefram@fysh.org> wrote:

> Ricardo SIGNES wrote:
> >So some of the options:
> >
> >1. deprecate assigning to these vars, giving a long deprecation period
> >(2yr) to let the deprecation warnings hit people using vendorperls;
> >after that period, assigning to $<,etc. is fatal
>
> I'd like to see us deprecate writing to $< et al.


I disagree with my past self here. I believe that getting rid of this will
break far more working code than it will "fix".

This functionality is usually used by scripts that have root privileges,
and hence pretty-much can't fail unless you're doing something silly. And
even outside of that (for example in a set-uid program) something like
«local $> = $<;» will essentially always succeed.

What would make more sense to me is to not let failures be silent. They
should either warn or die (as in autodie::variables). That way we wouldn't
break working code but still handle error conditions better.

We should definitely fix our terrible documentation for these variables to
actually describe how to use them sensibly though.

>
> Interestingly,
> and fairly unsurprisingly, making writing to them fatal doesn't cause
> any failures in the core test suite, which implies that the moderately
> tricky porting code around ID-swapping syscalls is all going untested.
> Quite apart from the error-prone usage, this maintenance issue is a good
> reason to punt this job to a module for which this is the raison d'etre.
>

It can't really be tested because anything interesting requires root
permissions (and possibly more), and that's an assumption we can't make in
our test suite.


> Of course, we need to have such a module that we can confidently point
> users towards.  Unix::SavedIDs (with bonus Unix::SetUser in the distro)
> looks somewhat like it could become that module, but it isn't there yet.
> (I suspect that this is the module that LeonT was referring to as a "good
> module on CPAN for [gs]etres[ug]id".)  Its test suite is broken on current
> Perls due to the removal of POSIX::tmpnam().  It's also a problem that
> it's specifically about setresuid(), which isn't available on all Unices
> that have saved IDs, let alone on all Unices.  Unix::SetUser probably
> needs to be split from Unix::SavedIDs, because its concept doesn't depend
> on having saved IDs.  So there's porting work to be done here.
>

Unix::SavedIDs or Perm::Uuid are excellent suggestions for in the docs, but
they only work on 3 platforms (Linux, FreeBSD and OpenBSD). That's not
enough for a true $> replacement.

Leon

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About