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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1948 Actions

    Problem Report Number 1948
    Submitter's Classification Specification problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0975
    Raised 1996-01-16 08:00
    Updated 2003-03-13 08:00
    Published 1996-01-24 08:00
    Product Standard Transport Service XTI
    Certification Program The Open Brand certification program
    Test Suite VST version 4.1.3
    Test Identification XTI.os/cots/accept 16
    Problem Summary TSDT4.013 This failure is related to the USL-011 change request - the "magic address switch." When a connection is accepted on a resfd != fd, some TCP implementations set the local address of the resfd to be th...
    Problem Text
    This failure is related to the USL-011 change request - the "magic
    address switch." When a connection is accepted on a resfd != fd, some
    TCP implementations set the local address of the resfd to be the same
    as that of the fd, even if the resfd was explicitely bound to it's own
    address.

    The test scenario is approximately:
    as root
    fd1 = t_open
    t_bind(fd1, reserved addr)
    as regular user
    fd2 = t_open
    t_bind(fd2, regular addr)
    t_listen(fd2)
    ...
    t_accept(fd2, fd1)

    On our implementation this will not cause t_accept to fail, since the
    address of the fd1 is completely ignored. The magic address
    switch takes place, and the reserved address of fd1 will never be
    heard of again. Thus an unprivileged user cannot used a reserved
    address via this mechanism.

    The test suite needs a "accaddrswtch" feature, so if the master system
    has this feature, this test can't be performed.

    The Chage Request is enclosed for reference.


    Document: X/Open Transport Interface (XTI)
    XO/CAE/91/600

    Change number: USL-011R'

    Source: UNIX System Laboratories, Inc.

    Title: t_accept() address binding for resfd in state T_IDLE

    Qualifier: Major Technical

    Rationale: Although some transport implementations (e.g., ISO)
    support multiple endpoints binding to the same protocol
    address, most TCP implementations do not. This
    limitation has led to the following widespread practice.

    A user calls t_bind() to bind resfd to an arbitrary
    port on the local host, then calls t_accept() (with
    fd != resfd) which binds resfd the same address as fd.
    For resfd, a change of address takes place. Thus this
    behavior is called as "the magic address switch".

    Appendix B.3, t_accept(), second paragraph, second
    sentence, states that "Also, resfd must be bound to the
    same address as fd." This requirement is not true for
    most TCP implementations. Moreover, this requirement
    makes the implementation of a compliant XTI interface
    over these TCP providers very difficult, if not
    impossible. Finally, the current practice based on the
    magic address switch works and applications are using
    it.

    In order to allow implementations that perform the magic
    address switch to comply with XTI, the following change
    is needed.


    Change: On p. 127, t_accept(), second paragraph:

    Remove second sentence:

    "Also, resfd must be bound to the same address as fd."

    Add the following text at the end of the same paragraph:

    "If such a restriction exists, a user has the
    following alternatives for accepting a connection
    on a different endpoint (resfd != fd): (1) call
    t_accept() while resfd is in state T_UNBND; or
    (2) bind to an arbitrary unused local address,
    and then call t_accept() in the T_IDLE state. In
    the second case, t_accept() will change the resfd
    address to be the same as that of fd. For
    portability, the first alternative is recommended.

    On p. 127, t_bind(), second paragraph change the
    beginning of the first sentence from:

    "In connection-oriented mode, ..."

    To:

    "In some implementation, in connection-oriented
    mode,..."

    Branding: Branding should require that a vendor state if multiple
    binds of an endpoint to the same address are allowed,
    and if not, whether the implementation performs the
    magic address during t_accept().

    Testing: An XTI implementation can and should be tested for
    allowing multiple binds of an endpoint to the same
    address and for performing the magic address switch.


    Test Output
    ************************************************************************
    /tset/XTI.os/cots/accept/T.accept 16 Failed

    Test Description:
    If the implementation supports a connection-oriented transport
    service:
    When the user does not have permission to accept a connection on
    resfd, then t_accept() returns (int)-1, sets t_errno to TACCES,
    and the states of the endpoints fd and resfd are not changed.

    Test Strategy:
    VERIFY that the transport service is of type T_COTS or T_COTS_ORD and
    that the provider does not require both fd and resfd to be bound to
    the same address
    CREATE privileged child process
    OBTAIN appropriate privilege using setprv(PRV_PROTADDR)
    OPEN an endpoint using t_open()
    INITIALISE endpoint using u_provinit()
    OBTAIN an address using u_privaddr()
    BIND the endpoint to the privileged address using t_bind()
    REMOVE privilege using unsetprv(PRV_PROTADDR)
    OBTAIN a second endpoint in T_INCON state using provsetup()
    ACCEPT connection using t_accept() with fd as second endpoint and
    resfd as first
    VERIFY that t_accept() returned -1 and set t_errno to TACCES
    VERIFY that the states of the endpoints have not changed

    Test Information:
    t_accept() on TCP endpoint
    RETURN VALUES: expected: -1, observed: 0
    TERRNO VALUES: expected: 3 (TACCES), observed: 0 (NO ERROR)
    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This is a known fault in the test suite for which a fix has previously
    been identified. It is recommended that a waiver is granted on the
    grounds of a Test Suite Deficiency.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority