Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0513 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0513.

Report 0513 Actions

    Problem Report Number 0513
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0132
    Raised 1996-08-27 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.3.5
    Test Identification XOPEN.os/procenv/ulimit 4
    Problem Summary PG4R.133 The current test case for ulimit 4 tries to double the current soft and hard file size limit. On our implementation the default file size limit equals to 0x7FFFFFFF which on our implementation equals ...
    Problem Text
    The current test case for ulimit 4 tries to double the current soft and
    hard
    file size limit.
    On our implementation the default file size limit equals to 0x7FFFFFFF
    which
    on our implementation equals RLIM_INFINITY.

    When the test suite tries to double the current limit, it thus tries to
    set it
    to something that is beyound RLIM_INFINITY.

    Our implementations behaviour in such cases is to return ok for
    ulimit(UL_SETFSIZE)
    and keep RLIM_INFINITY as the limit.
    That's why ulimit(UL_GETFSIZE) returns 4194303 (RLIMIN_INFINITY = 512 *
    4194303).

    If we change our default value for the file size limit (thats a tunable
    parameter)
    to e.g. 0x1FFFFFFF the above test PASS without problems.

    The XSH specification is somewhat unclear on this point. The DESCRIPTION
    for UL_SETFSIZE states (p. 684):
    The hard and soft file size limits are set to the specified value

    multiplied by 512. If the result would overflow an rlimit_t, the
    actual value set is unspecified.

    In our case, the result overflows the RLIM_INFINITY.

    We believe that the test suite should be changed to test whether or not
    the current file size limit
    equals RLIM_INFINITY. If that is the case, the test suite should
    initiately lower the file size
    limit and then try to raise it again (with appropriate priv. but below
    RLIM_INFINITY).

    We believe that the specification does not handle the situation with
    RLIM_INFINITY/unlimited
    file size limit. The specification could be updated as specified below:

    Either:
    change "overflow an rlimit_t" to "overflow the RLIM_INFINITY"

    or:
    Explain that setting values greather than RLIM_INFINITY will just
    retain
    RLIM_INFINITY

    or: update the ulimit pages to be in line with the
    getrlimit/setrlimit (RLIMIT_FSIZE) pages.
    The new XSH Specification (issue 5) for getrlimit/setrlimit takes
    good care of the above
    mentioned situation. The new XSH specification (issue 5) of
    ulimit also needs updating.
    Test Output
    400|694 4 1 00:17:45|IC Start
    200|694 4 00:17:45|TP Start
    520|694 4 3589 2 1|ulimit(1) returns 4194303 when 8388606 expected
    220|694 4 1 00:17:45|FAIL
    410|694 4 1 00:17:45|IC End
    4

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The submitter's suggestion that the test should first lower the
    ulimit before raising it is in fact exactly what the test does.
    However, the lowering is done in the main test executable (in the
    function ch_t4() in ulimit.c) before the tet_exec() of the set-uid
    part of the test. It appears that the implementation is resetting
    the ulimit to the default value in the set-uid executable, instead
    of inheriting the ulimit across the execve() call as required by
    the XPG.

    It is recommended that this waiver request is refused.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    There is insufficient evidence to grant a Test Suite Deficiency. However
    if the customer considers that there is a specification issue, this should
    be raised as a formal change request.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority