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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0526 Actions

    Problem Report Number 0526
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0145
    Raised 1998-06-03 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Network File System
    Certification Program The Open Brand certification program
    Test Suite VSX4+XNFS version 4.4.2
    Test Identification POSIX.os/files/chmod 5,6
    Problem Summary PG4R.146 Our chmod man page 020#0 set group ID on execution if # is 7, 5, 3, or 1 enable mandatory locking if # is 6, 4, 2, or 0 We don't support file locking via the chmod() interface over NFS. Is this a pro...
    Problem Text
    Our chmod man page

    020#0 set group ID on execution if # is 7, 5, 3, or 1
    enable mandatory locking if # is 6, 4, 2, or 0

    We don't support file locking via the chmod() interface over NFS.
    Is this a problem for the test suite or is there a way to change
    a config parameter to cause this to not produce errors?

    Also, below is the response from our inquiry to
    vsx_support@rdg.opengroup.org with respect to this matter:

    The XSH specification does not say anything about mandatory
    locking - thisusage of the S_ISGID bit is an extension to the
    specification. In most cases, the test suite is not affected by
    extensions to the specification, usually because the extensions
    need to be enabled somehow in order for applications to make use
    of them, and the test suite does not enable them. You seem to
    have come across a case where an extension does affect the
    test suite.

    I don't see this as a problem for the test suite. The tests are
    written to expect the behaviour described in the specification.
    If a system has implemented an extension which causes its behaviour
    to differ from that expected by the test suite, then the question
    is whether this alternative behaviour is allowed by the
    specification.

    The appropriate way to obtain an `official' answer to this question
    would be to submit an XSH4 interpretation request asking for a PIN
    to be granted. My feeling is that for this particular case the
    behaviour is probably OK, courtesy of the text in section 2.3
    "Error Numbers", which says

    "Implementations ... may generate errors included in this list
    under circumstances other than those described here"




    Test Output
    /tset/POSIX.os/files/chmod/T.chmod{5,6}
    =======================================

    chmod("chmod-t.5", 02000) did not give correct results
    RETURN VALUES: expected: 0, observed: -1
    ERRNO VALUES: expected: 0 (NO ERROR), observed: 22 (EINVAL)

    chmod("chmod-t.5", 02400) did not give correct results
    RETURN VALUES: expected: 0, observed: -1
    ERRNO VALUES: expected: 0 (NO ERROR), observed: 22 (EINVAL)

    chmod("chmod-t.5", 02200) did not give correct results
    RETURN VALUES: expected: 0, observed: -1

    chmod("chmod-t.6", 02000) did not give correct results
    RETURN VALUES: expected: 0, observed: -1
    ERRNO VALUES: expected: 0 (NO ERROR), observed: 22 (EINVAL)

    chmod("chmod-t.6", 02400) did not give correct results
    RETURN VALUES: expected: 0, observed: -1
    ERRNO VALUES: expected: 0 (NO ERROR), observed: 22 (EINVAL)

    chmod("chmod-t.6", 02200) did not give correct results
    RETURN VALUES: expected: 0, observed: -1
    ERRNO VALUES: expected: 0 (NO ERROR), observed: 22 (EINVAL)

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    I recommend forwarding for a working group review, with the
    recommendation that a PIN be granted. The rationale is that
    section 2.3 Error Numbers permits errors to be generated
    for circumstances other than those described in the specification.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request should go for a 14 day review

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The NFS specification does not allow restrictions on valid modes
    from XSH. It allows "silent" denial of setuid/gid privileges by
    ignoring the mode bit, and can deny acces via UID mapping, but
    does not allow for denial of otherwise valid modes.

    In this case, "silent denial" means that the server just doesn't
    set the SETUID or SETGID bits, but doesn't return an error when it
    doesn't. This particular implementation doesn't seem to be so
    silent, so it is in violation.

    Even if the server allowed the setting of the SETGID bit, it would
    be forced to deny READ requests to such a file because the SETGID
    bit also describes mandatory locking which is not supported via NFS.
    The NFS server would be susceptible to denial of service attacks if
    it actually attempted to access such a file because a malicious user
    could lock the file on the server or on a different client, then try
    to read the file from the original client. The NFS server would
    have to hang, waiting to acquire the lock, which it would possibly
    never get.

    It is argued that mandatory locking is a questionable concept
    outside of NFS, and is far worse when considered with NFS. But,
    despite the problems with mandatory locking, there are users who
    use it (for local access). Consider the following scenario: a user
    has a system S that runs local jobs but does not have a tape drive,
    and another system T that does have a tape drive. To load files off
    T's tape drive onto S, the user configures S to NFS export its
    filesystems to T. Now suppose the user wants to load from tape a
    file that has the mandatory locking bit set. The archive program
    (e.g., cpio) will create the file, write to it, and then use chmod()
    to set the file's permission bits, including the mandatory locking
    bit. The implementation in question would not permit this, because
    the final chmod() would fail. This is not useful behavior, given
    that T will do no further processing of the file after setting the
    mandatory locking bit.

    The request should therefore be rejected.

    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