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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1678 Actions

    Problem Report Number 1678
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0482
    Raised 2002-04-10 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.1.2
    Test Identification CAPI.os/files/mknod 13
    Problem Summary PG4U.00185 This IR claims that the behaviour of mknod() for file types other than FIFOs is unspecified, even when an error condition listed in XSH occurs.
    Problem Text
    The VSU test code looks like this:

    mode = S_IFBLK | S_ISUID;

    tet_infoline("TEST: A call to mknod() returns -1 when mode is not");
    tet_infoline(" FIFO-special and process does not have");
    tet_infoline(" appropriate privileges");
    if ((s2 = mknod(test_file, mode, (dev_t)0)) != -1)

    the standard states the following:

    The only portable use of mknod() is to create a FIFO-special file. If mode is
    not S_IFIFO or dev is not 0, the behaviour of mknod() is unspecified.

    As can be seen from the code, S_IFIFO is not used in the test, therefore the
    test is trying to test behaviour that is not specified by the standard.
    Test Output
    ************************************************************************
    /tset/CAPI.os/files/mknod/T.mknod 13 Failed

    Test Description:
    Base Required Deviance
    EPERM in errno and return -1 on a call to int mknod(const char *path,
    mode_t mode, dev_t dev) when the process does not have appropriate
    privilege and the file type specified by mode is not FIFO-special.

    Test Information:
    TEST: A call to mknod() returns -1 when mode is not
    FIFO-special and process does not have
    appropriate privileges
    TEST: A call to mknod() sets errno to EPERM when
    mode is not FIFO-special and process does not
    have appropriate privileges
    ERROR: mknod() did not set errno to the correct value
    Expected: 1(EPERM) Received: 22(EINVAL - Invalid argument)

    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    As well as the text quoted by the submitter, the specification also says:

    "The file type ... must be selected from one of the following
    symbolic constants" (followed by a list which includes S_IFBLK)

    and

    "Only a process with appropriate privileges may invoke mknod() for
    file types other than FIFO-special."

    and

    "The mknod() function will fail if:

    [EPERM] The invoking process does not have appropriate privileges
    and the file type is not FIFO-special."

    While at first sight there appears to be a conflict between these
    statements and the statement that the behaviour is unspecified when
    the file type is not S_IFIFO, this is not necessarily the case.
    It is common for the DESCRIPTION section to describe just the
    successful behaviour of a function, and for errors to be covered
    only in the RETURN VALUE and ERRORS sections. Thus the text in the
    DESCRIPTION section should be treated as being prefixed by an
    implied "In the absence of any error conditions, the function behaves
    as follows..."

    Therefore, I believe that the intention of the text "The only portable
    use of mknod() is to create a FIFO-special file. If mode is not S_IFIFO
    or dev is not 0, the behaviour of mknod() is unspecified.", which appears
    in the DESCRIPTION section, is only that the behaviour of successful
    calls for file types other than S_FIFO is unspecified. It should not be
    taken as cancelling out the clearly specified behaviour when any of the
    listed error conditions is in effect.

    It is recommended that this request is refused.

    Note however, that there does appear to be a bug in this test.
    The failure looks to be due to a simple error precedence issue.
    If zero is not a valid dev_t value for a block device, and the
    system checks the dev_t value before it checks for privilege,
    then the call would legitimately set errno to EINVAL instead of
    EPERM. The test should be changed to allow for this.

    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