in create_session we were sending auth_none as available security types
for the callback channel. Adding auth_sys to the list. No enforcement of
these creds happens.
this function was called before writes and was setting time and size
attributes of the file. we were translating it into a setattr. reads
were also followed by a setattr of timestamp (unnecessarily)
instead of updating the attribute cache with the values given to SETATTR, add a GETATTR to the compound; this will capture changes to time_modify and change that the client could otherwise miss, and get the server's value of timestamps sent with SET_TO_SERVER_TIME4
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
removed issue for nfs_mount.exe not listing mounted drives
modified issue for renaming on top of an open file (now returns an error)
added issue suggesting DisableDfs
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
handling receiving WRONGSEC error in compound_encode_decode function by
sending either SECINFO or SECINFO_NONAME op to find out available
security flavors from the server. then try to establish new security
context given the ordered list returned by the server.
Not handling if parent directory doesn't permit a security flavor of
its child directory. Example "/" exported with only auth_sys and
"/sec" exported with only "gss".
proposes an alternate solution for attempts to set file size without an open sta
teid. instead of acquiring one by sending OPEN, fail the request with ACCESS_DE
NIED
according the MS File System Algorithms documentation for setting FileAllocation
Information and FileEndOfFileInformation [http://msdn.microsoft.com/en-us/librar
y/ff469355%28v=PROT.10%29.aspx]:
"If Open.GrantedAccess does not contain FILE_WRITE_DATA, the operation MUST be f
ailed with STATUS_ACCESS_DENIED"
-removes open_owner_id, access_mask, access_mode from setattr upcall arguments
-moves map_access_2_allowdeny() back to open.c as a static function, since handl
e_setattr() was its only other call site
Deleting client's security context was causing kernel crashes.
During upcall, we remember a pointer to the client's security context,
then on close we delete the security context. Previously we would also
delete the context if the upcall was abandoned.
Apparently, windows will always send a close for the fcb that was used
for the abandoned upcall. Close deletes the context. Then when upcall
was done, it would try to delete the context again (oops).
nfs41_name_cache_lookup() was returning FILE_NOT_FOUND on negative entries, but still copying the target filehandle
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
zero-length ranges: valid on windows, but nfs servers MUST return NFS4ERR_INVAL for LOCK with length=0. use MRxIsLockRealizable() to return STATUS_NOT_SUPPORTED for zero-length ranges (avoiding the lock upcall and rpc)
ranges that extend past UINT64_MAX: not valid on windows. NFS expects length=UINT64_MAX for locking to end-of-file. use length=UINT64_MAX if length >= UINT64_MAX-offset (making lock ranges consistent with linux client)
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
previously, if the supplied buffer length was smaller than the result
of the volume query we returned SUCCESS and no data (ie. it was needed
because Notepad passes in a buffer too small but doesn't like a
buffer_too_small error.) However, it does work with buffer_overflow
error and then a partial resulted returned.
if during recv we received an error, then propagate that to the caller.
otherwise, do time out check. also do timeout check if the thread's xid
didn't match received xid (making sure we'll timeout if we have a starving
thread that will never receive a reply)
if we are doing CREATE_NEW file creation, then based on whether or not
we have a persistent session, we'll send either GUARDED4 create for
persistent session and EXCLUSIVE4_1 create otherwise.
if we receive an rpc_autherr, just recreate a new rpc client as well
as the rpc auth structure. as it ties into the recovery and handles
that only one thread recovers and reestablishes the rpc auth context.
in theory, reestablishing rpc client does not necessitate new rpc auth
context. we really need to restablish one only if we get rpc autherr. however,
it simplifies the code not to introduce a different synchronization
mechanism for rpc auth in addition to the rpc one.
once libtirpc blocking recv was changed to a polling receive,
we no longer had a timeout mechanims on waiting for a reply.
solution: save a timestamp before the recv call, on each async recv return
check if the time lapsed does not exceed the timeout value. when timeout
is reach, return TIMEDOUT rpc error.
