windows api frequently sends a query security with a buffer len of 0
to figure out how big of buffer is needed for a security descriptor.
we send a getattr for acl attribute on the 1st irp, then cache the
returned security descriptor in fobx. on the 2nd query, if the buffer
is cached and it's not "stale", we return that buffer.
added 2011 year to the copyright line
added authors info to the license
added UofM license to libtirpc files that we modified
(but i probably missed some)
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)
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).
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.
every upcall (except few) pass session and open_state pointer, so
add that to marshal_nfs41_header() in the driver. remove passing
of session and open_state elsewhere in marshal functions.
in the deamon, upcall.c now reads and stores pointers to session
and open_state in nfs41_upcall datastructure instead of having
each individual upcall store their own pointers. setattrl
and readdir args keeping pointer because the rest of the code
uses them a lot.
in upcall_parse() up refcounts on session and open_state if
valid handles were passed in. down refcounts upcall_cleanup() as
before. but need to be careful with count value for mount and open
upcalls. we need to take an extra ref because upcall_cleanup() now
will always decrement it.
instead of passing sids for the owner and group, create a security
descriptor and pass that back. this way we can add all the security
information that was queried in the daemon and pass a fully formed
security descriptor back to the kernel.
notice: irp_mj_query_security provides a pointer to the buffer that
suppose to hold the security descriptor. that memory is valid only
in the context of the process doing the security irp. we can't use
this pointer in then upcall entry and try to write the security
descriptor directly there as we process the downcall. that leads
to kernel oops.
thus we have to first allocate memory to hold the security descriptor
then copy bytes passed to us from the daemon. then do another copy
with the context of the security irp.
Problem: say nfsd is not running but the redirector is active already
(ie. start deamon, stop deamon). problem doesn't exist if nfsd has never
been started. now a user process executes a mount command, the kernel
ends up creating a system thread to handle creation of the vnetroot.
that thread places a mount upcall and waits for the down call. now
kill the user process. now start the nfsd. it will pick up a queued up
upcall entry. however, in the arguments there are pointers to server name
and mount point values that are stored in the memory of the user process
that started the mount but now ended.
Solution: check that Mount.srv_name and Mount.root are still valid
addresses before dereferencing them.
Basic handling of owner and group security query (no dacl).
Added new upcall for NFS41_ACL_QUERY (driver and daemon code).
Daemon, upon getting NFS41_ACL_QUERY first places a getattr that has
owner, group attribute request. We currently don't cache them!!!
Then, we parse nfs4name format (ie user@domain or group@domain)
into user and domain. We currently ignore domain part!!!
Then, we assume that whatever we are mapping is "known" locally
(ie LookupAccountName() api which retrieves a SID for a given name).
Mapping from name to SID can only be done in the userland. We then
copy the bytes via the upcall pipe to the kernel. If the received
user or group cant be mapped via LookupAccoundName(), we create a
well known null SID as the reply.
Kernel creates a security descriptor in the absolute-format and adds
owner and group sids to it. Important: RtlSetOwner/Group functions only
work with absolute-format security descriptor, however the reply to the
user needs to be in the self-relative format.
The way security query works is that it passes us a buffer to be filled
with the security context. However the user doesn't know how big the
buffer should be so, the user is allowed to pass a null buffer and have
the kernel return how much memory is needed. This leads to 2 security
queries => 2 NFS41_ACL_QUERY upcalls => 2 getattr rpcs... It should be
improved.
TODO:
- need to add caching of owner/group attributes for a file?
- need to add calls to LDAP for more general mapping?
- need to cache reply of the ACL if supplied length is 0?
connectathon locking tests trigger an interrupted UNLOCK upcall, which leads to the bugcheck in CloseSrvOpen() when freeing the security context
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
leaving CLOSE upcall non-interruptable as it leads to issues with security context.
making all other upcalls interruptable so that when something goes wrong we can ctrl-c out of a user application. otherwise, the machine requires a reboot (ie caz the wait we made the wait non-interrutable so nothing can kill it).
switching user's upcall wait from being UserMode and TRUE (interruptable) to KernelMode and FALSE. msdn doc does recommend for simplicity of the drivers to do that.
it seems to no longer generate interrupts on close irps but we are still able to ctrl-c running tests.
instead of getting security context on every upcall, acquire security context on open and save it in fobx. cache manager does read and write calls in a system csecurity context not in users, thus we need to use the context of the open instead.
previously we noticed that calling MmUnmapLockedPages() causes kernel crashes (thus the code is if 0-ed). however, when we don't unmap memory, it keeps accumulating in the nfsd's process memory (and is never "freed").
in this patch
(a) calling unmap
(b) checking if MmMapLockedPagesSpecifyCache() returns us a NULL pointer which is a type of failure that doesn't throw an exception but still is a failure.
(c) cosmetic change to printf.
NOTE: this cause still leads to failures for general tests. Running them in a loop (previously produced kernel crashes) now just leads to test failing. the cause is unknown!
even though we might have the same server mounted under 2 drive letters, make it so that you can't umount if any files are opened in that netroot.
not checking for that allows us to umount the driver while it is still in use. then there is no way to "unmount" from nfsd's perspective and it'll have that session and connection going forever.
passing "false" to RxFinalizeConnection makes it so that when files are opened it won't allow the unmount, but when the files are closed, it will successfully unmount but RDBSS never call FinalizeNetRoot() function and thus we never really unmount.
i noticed that FinalizeVNetRoot() is never called. Returns from FinalizeNetRoot() are ignored so we can't fail there if we have opened files.
if we see NFS4ERR_NO_GRACE from recovery operations, it means we lost our state due to a lease expiration rather than a server reboot. in this case, it's possible that conflicting locks were granted to other clients, so we have to try normal OPEN/LOCK operations to recover our state. because they're sent during recovery, nfs41_open() and nfs41_lock() take a new 'bool_t try_recovery' argument so we can avoid recursion
if these operations fail due to conflicting locks, we have no choice but to return errors to the application. using a stateid that was revoked due to lease expiration results in NFS4ERR_EXPIRED, and we map this error to ERROR_FILE_INVALID: The volume for a file has been externally altered so that the opened file is no longer valid.
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
to determine that the daemon has restarted -- rather that daemon is receiving upcalls from the kernel that were processed by the old instance of the daemon -- add a version to the upcall mechanism.
when daemon starts up it generates a version number (just a timestamp). it passes this value to the driver on start up via "start_ioctl" downcall. the driver saves that value in its device extensions. it uses that value in the mount and shtudown upcalls.
when daemon replies to the mount command it again sends its version as a part of the reply. this reply is stored in driver;s netroot extensions. the driver uses netroot's value in each upcall to the daemon.
if the daemon receives an upcall for an operation where the included version does not equal to the its current version, it fails the upcall (error_code=116).
a restart of the daemon would change driver's device extension value which the driver will then use in the new mount upcalls that would establish new sessions. then the correct daemon version would be returned as a part of the mount downcalled and saved in the netroot.
IOCTL_NFS41_DELCONN had a check for RxDeviceObject->NumberOfActiveFcbs before calling nfs41_DeleteConnection(). this prevents us from unmounting even if the netroot has no open files, and is redundant because nfs41_FinalizeNetRoot() already has the necessary check for NetRoot->NumberOfFcbs/SrvOpens
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
fixes a memory leak that occurs when a readdir loop doesn't complete, since the cookie was only freed on the last readdir upcall. by storing the cookie with nfs41_open_state, we can avoid passing the cookie to the driver and back, and not worry about having to free it separately
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
if the thread placing an upcall was woken up from the sleep, but have not been picked up by the daemon thread from the upcall queue, we would just cancel the upcall. thus nfsd would never see it. however, it was causing leaks in the open state. we would allocate open state but matching close would never make it to the daemon.
instead, always place an upcall to the daemon, but mark it that nobody is waiting for it if the requesting thread gets interrupted and goes away.
