Hi.

The attached patch will address a problem where the NFSv3 server
incorrectly sets the mode of a newly created file.  This can occur
when the directory, which contains the newly created file, has a
default ACL on it which causes the mode to changed from that which
was specified in the over the wire attributes.

This problem results from some changes made to the NFSv3 server to
address an interoperability problem which occurred when the Solaris
NFS client was modified to treat file times as signed quantities
instead of unsigned quantities and to return errors to its
applications which it sees file times which appear to be negative.

The NFSv3 exclusive create mechanism works by the client sending
a 64 bit verifier in the over the wire CREATE request.  The Linux
server then breaks up this 64 bit verifier into two 32 bit quantities
and stores them as the initial values for the mtime and atime fields
for the newly created file.  If another CREATE request comes in, the
NFS server can then compare the mtime and atime fields against the
verifier in the new CREATE request in order to determine how to
correctly handle the request.  The server will either fail the
request with EEXIST or treat it as a retransmitted and proceed as
if it is the original request.  After the client successfully receives
a response to its exclusive CREATE request, it is responsible for
sending an over the wire SETATTR to set the mtime and atime fields
to the current time.

The problem with the Solaris client was that it was receiving the
intermediate attributes, ie. the ones that contained the verifier
that it itself had constructed, and based on these attributes,
was failing the exclusive create system call.  This is a bug in
the Solaris NFS client.  A workaround has been implemented in the
Solaris client to ensure that the sign bit in the 64 bit verifier
is not set.  The correct fix would have been to ensure that it just
didn't fail the CREATE call based on the intermediate attributes.

However, this situation was worked around in the Linux NFS server.
The solution was to ensure that the mtime and atime fields were
not negative by masking the two halves of the verifier.  The
leftover two bits were then stored in the mode field.

This then causes the problem which is being seen by NFSv3 clients.
The mode, from the initial attributes in the CREATE request, is
used and is then modified by the contents of the default ACL to
construct the mode of the new file.  The NFS server then changes
the mode to the mode contained in the initial attributes in the
CREATE request.  This can cause the mode to be different than it
should have been.  Thus, the mode comes out differently, based
on whether the file was created locally on the server or via NFS
from a client.

This problem was then worked around in the Linux NFS client by
having it send an NFS_ACL SETACL request making the default ACL
on the directory to be the access ACL on the newly created file.
This causes the mode to be set back to the correct value again.

This solution works for clients who know to send the extra
NFS_ACL call.  It does not work for any other clients, NFS_ACL
aware or not.  It also introduces a performance penalty due to
the extra over the wire operation.

The solution is to modify the Linux NFS server to just mask off
the two sign bits of the halves of the verifier which are stored
in the mtime and atime fields and forget about the two sign bits.
This leaves the mode computations alone and thus, the mode comes
out correctly.  This solution works for clients who don't know
to send the extra NFS_ACL request, clients who don't know anything
about NFS_ACL, and the updated clients who are sending the extra
NFS_ACL request.

This does introduce a slight danger if the client really was
depending upon these two bits to differentiate between different
exclusive CREATE requests.  However, given the algorithms used
by most clients, where one half is the current time on the
client and the other half is the pid of the process or the IP
address of the client, then this danger is minimal.

The attached patch removes the support for the use of the mode
field to store the two bits of the verifier.  It has been tested
using the Connectathon testsuite as well as the test scenario
described in the Red Hat bugzilla:

     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128616

    Thanx...

       ps

Signed-off-by: Peter Staubach <staubach@redhat.com>