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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0524 Actions

    Problem Report Number 0524
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0143
    Raised 1998-02-12 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 XNFS.prtl/proto/mnt 10
    Problem Summary PG4R.144 This test is testing Section 8.2.5.4 (page 113) of the XNFS spec. The test and the specification expect MNTPROC_MNT(dir) to return ENOENT errno if the directory or file does not exist. This will allow...
    Problem Text

    This test is testing Section 8.2.5.4 (page 113) of the XNFS spec.
    The test and the specification expect MNTPROC_MNT(dir) to return
    ENOENT errno if the directory or file does not exist. This will allow
    an application to determine what directores/files exist on the
    system. We believe that this is a security problem and the
    specification is in error requiring ENOENT for this case. EACCESS
    would be better errno since it states nothing about the existance
    of the file or directory in question.


    We would like this IR to be submitted for a 14 Day review by the
    working group.
    Test Output
    /tset/XNFS.prtl/proto/mnt/T.mnt 10 Failed
    Test Description:
    When the path dirname refers to an exported file system and dirname
    does not exist on that file system, then a call to
    MNTPROC_MNT(dirname) returns MNT_ENOENT in fhstatus.status.

    Test Strategy:
    SERVER:
    EXPORT directory
    CLIENT:
    CALL MNTPROC_MNT for non-existent sub-directory of exported
    directory
    VERIFY that MNTPROC_MNT set status to MNT_ENOENT
    SERVER:
    UNEXPORT directory
    Test Information:
    MNTPROC_MNT returned status = MNT_EACCESS (13) instead of MNT_ENOENT (2)

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    There seems to be a reasonable case for choosing to change the
    behaviour of the system in this way. However, strictly speaking the
    request should be refused - this is requesting a PIN to be issued for
    a grey area, but there is no grey area here. The specification is clear
    that MNT_ENOENT must be returned.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request is being sent for a 14 day review.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This XNFS interpretation request should be refused.

    The XNFS specification does not impose a behavior that gives reason
    for security concerns. While it is true that in some circumstances
    the server should return MNT_EACCES for security reasons,
    the test case is not one of them. This is because the non-existent
    directory is a direct child of a directory that the client can mount.

    The two return codes in question are as follows (XNFS p.113)

    MNT_EACCES: Indicates that the call failed because
    access to the specified directory was denied.
    Either no directory in the path dirname is
    exported, or the client system is not permitted
    to mount this directory.

    MNT_ENOENT:If server exports only /a/b, an attempt
    to mount /a/b/c will fail with ENOENT if the
    directory does not exist; on the other hand, an
    attempt to mount /a/x would fail with EACCESS.

    For a client with export priveliges to /a/b, an error return of ENOENT
    can provide relevant information about the underlying filesystem.
    And why not? This client could mount /a/b to look at the filesystem.
    If /a/b does not exist, this client should have knowledge of that too.
    For all other cases, (non-privileged requestors,and filesystems that
    are not exported, EACCES should be returned.

    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