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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0516 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 0516.

Report 0516 Actions

    Problem Report Number 0516
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0135
    Raised 1997-02-19 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.136 We have previous asked for an interpretation for this test case PG4R.133. We agree with the consultants response that the test case do lower the ulimit before it tries to execute the test case. We als...
    Problem Text
    We have previous asked for an interpretation for this test case PG4R.133.
    We agree with the consultants response that the test case do lower the
    ulimit before it tries to execute the test case. We also agree that our
    implementation resets 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. We do not agree that the waiver should be refused.

    The current test case tests as required by the spec (although everybody
    can PASS by setting HARDLIMIT > 2 * SOFTLIMIT). However, we believe the
    spec is in error for the following resons:

    1) Our implementation is historic SVR4 behavior.
    The intention of the Single UNIX Specification was not to break with
    historic behavior. changing the code will introduce compatibility
    problems and there could be applications who depend on this behavior.

    2) The requirement represents a security hole.
    We believe that it is risky to simply have the resource limits inherited when
    a non-privileged user execs a set[ug]id executable. That is why the code
    is in there. Many programs can be made to malfunction by changing
    resource limits. The requirement is a needless and risky behavior.

    3) Historic SVR4 code makes an explicit check to see if the SUID bit is set
    or not. If the SUID bit is set, then the resource limittations are restored
    from the systems defaults. The only reason for this check is to prevent
    UNPRIVILEGED processes from enforcing resource limitations on setuid/setgid
    processes.
    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 expected behaviour as per the specification, requires
    that the new process inherits the resource limits across an exec()
    call. 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.

    It is recommended that this request be refused.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    After review, the majority of the responses agreed with the consultant.

    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