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

Re: setuid and serious trouble (Re: Time to update POSIX.pm?)

Thread Previous | Thread Next
From:
Mark Overmeer
Date:
February 3, 2011 07:23
Subject:
Re: setuid and serious trouble (Re: Time to update POSIX.pm?)
Message ID:
20110203152302.GC13263@moon.overmeer.net
* Tom Christiansen (tchrist@perl.com) [110203 13:57]:
> I haven't looked into the matter in detail. I do know that there
> may now be something of a mismatch between traditional setxid
> semantics of two different id sets wherein setting the real id
> was a one-way trip,

Actually, the setuid() was only a minor detail. I think that solution
is quite simple: the module is named POSIX, so should follow the
standard as close as possible (which is already the case). You do not
have to compare different OSes to see what functionality should be in
there.

No, what I ment is my other remarks about the module as a whole.
Collected from various message over the past few days (and extended)

  . From the 1125 POSIX standard functions, POSIX.pm only provides
    about 200.

  . From those 200, about 80 are implemented to produce an error.

  . Many of these errors are wrong. People try to use atoi(), because
    they are used to it in other languages. Perl does not offer that
    function, although it could:
      sub atoi { no warnings; int($_[0]+0) }
    The implementation, however, croaks with "atoi() is C-specific, stopped"
    The manual explains how to implement atoi() in Perl.
    Is it useful to provide a function which croaks? (when 900 other,
    also missing functions, are just unknown)

    The function atoi() is not C-specific: the function is defined
    by POSIX and available in C. Programmers in any language do often
    need to convert ascii strings into integers. They look into Perl's
    POSIX man-page and should be able to figure-out how to do that
    trick in Perl.

  . From those 200 functions provided, about 50 are bluntly forwarded
    to Perl functions with the same name. In most cases, these Perl
    functions are much smarter than the POSIX function. Are you still
    providing a real POSIX interface this way?
    For me, POSIX function getpwnam is not equivalent to Perl's
    implementation. Probably I am quite more strict than other people
    in this respect.

  . From the remaining 200-50-80 ~ 70, some are implemented in XS,
    although perl itself has other (often better) ways. For instance
    setuid() via $< is more portable.

What I would like to see happening to the POSIX module is:

  . remove the autoloading: it slows everything down with 150 files
    of each about 12 lines.

  . remove all implementations which croak. It is only a small subset
    of all functions of POSIX. The messages are usually wrong anyway.

  . remove all functions which are simply forwarding to Perl core
    functions with the same name (but usually much smarter)  This
    may break some code, because core uses prototypes. In general,

    I think that it is a very bad idea that these to example scripts
    produce a different result:

         my @l = (1,2,3);
         exit @l;

         use POSIX 'exit';
         #... a zillion lines inbetween...
         my @l = (1,2,3);
         exit @l;

    Some regressions are permitted between major perl releases. Is this
    too much?

  . only keep the functions of POSIX which are not supported by
    Perl core. And, of course, all those constants it defines.
    The code in the module would become small (no need to cut it into
    pieces, Leon)

  . for Perl 5.14, produce a "deprecate" warning when people explicitly
    request functions which have been removed. When an import of
    'exit' is requested, you polity say: "See the POSIX manual for
    compatible functionality".

  . IMO, the POSIX.pod manual should become the starting point for
    people with little Perl knowledge but a lot of POSIX experience,
    for instance all C programmers...

    I think we should try to propose implementations for all POSIX
    functions or explain why they are not needed. Mainly in a table
    with explanation

     | POSIX       | in Perl              | how to use    |
     | fabs(f)     | perlfunc abs         | abs($f)       |
     | lowercase(c)| perlfunc lc          | lc($c)        |
     | setuid(i)   | perlvar $UID         | $UID = $i     |
     | memcpy      | automatically        |               |
     | exit(i)     | perlfunc exit        | exit $i       |

    Probably in sections, for instance the fabs should be in one
    table with the other mathematical functions. In the same
    section, you would explain (or refer to) integer-float
    conversions, Math::Big* existence and so on.

    Most of the text should focus on people with little knowledge of
    Perl but more experience with POSIX.

So: above is my wish. I would like to hear your (and other peoples)
feeling towards implementing one or more of these changes before I
produce patch-sets for them.

This could be ready within a week from now (simply removing most code,
rewrite of the manpage is the real task) But I can do other things with
my time if nobody cares...
-- 
Regards,
               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       Mark@Overmeer.net                          solutions@overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net

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