[jcifs] Unexpected fragment length exception when retreiving ACLs/SIDs on a file that has explicit permission granted to a deleted user

[Colin Dean]

Although the changelog does not appear at glance to have addressed a
problem that could cause this error, I should note that we're using jcifs
1.3.15 in this particular case. We're in the process of deploying 1.3.18.


Colin Dean/Pittsburgh/IBM wrote on 04/27/2015 15:09:10:

> From: Colin Dean/Pittsburgh/IBM
> To: jcifs at lists.samba.org
> Date: 04/27/2015 15:09
> Subject: Unexpected fragment length exception when retreiving ACLs/
> SIDs on a file that has explicit permission granted to a deleted user
>
> Hello,
>
> I’m encountering an unexpected exception while retrieving SIDs/ACLs
> for a file served by Windows Server 2012 Standard Edition. We’re
> running on Windows in this instance, if that matters.
>
> Caused by: java.io.IOException: Unexpected fragment length: 28757
>            at jcifs.dcerpc.DcerpcPipeHandle.doReceiveFragment
> (DcerpcPipeHandle.java:96)
>            at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:220)
>            at jcifs.smb.SID.resolveSids(SID.java:94)
>            at com.vivisimo.connector.smb.SMBConnector.resolveSids
> (SMBConnector.java:629) ... 10 more
>
> This is approximately where our code hands off to jcifs to resolve the
SIDs:
>
>             SID[] sidsToResolveArray = sidsToResolve.toArray(new SID[0]);
>             try {
>                 LsaPolicyHandle policyHandle = null;
>                 try {
>
>                     policyHandle = handle.openPolicyHandle(file);
>                     SID.resolveSids(handle.getHandle(),
> policyHandle, sidsToResolveArray);
>
>                 } finally {
>                     if (policyHandle != null) {
>                         LOGGER.debug("Closing Policy handle for [" +
> file + "]");
>                         policyHandle.close();
>                     }
>                     policyHandle = null;
>                 }
>             } catch (IOException e) {
>                 throw new ConnectorException(e);
>             }
>
> It dies shortly after we call SID.resolveSids() there in the middle
> of the inner try.
>
> We have a few theories:
>
> 1. This filesystem has a lot of files with Japanese characters in
> the filename. We considered that perhaps jCIFS or our software using
> it lacks support for Japanese characters, but we set up a testing
> environment with a bunch of files with Japanese filenames and it
> works for us. We’re pretty certain that our configuration mirrors
> that of the erring environment, but there might be subtle
> differences were are not able to replicate (e.g. real data instead
> of made up test data).
>
> 2. All of the files that are failing (we’re crawling a filesystem)
> share one trait: they have what appears in the Windows properties a
> permitted user that shows as “unknown user”, which may be an
> artifact remaining after the user was removed but its explicit
> permissions remained. Processing on a directory that has no “unknown
> users” yields no failures.
>
> This leads me to believe that jCIFS is failing on unknown users.
> However, looking through the source, I don’t see an obvious way to
> detect this.
>
> The obvious workaround appears to be “clean your unknown users” but
> I think this could be detectable and loggable during our processing
> of the share.
>
> I’d appreciate input on this.
>
> Colin Dean
> Advisory Software Engineer & Tech Lead, Watson Explorer Connectivity
> email: colindean at us.ibm.com | tel: +1 (412) 315-2066
> Find me on: [image removed]  [image removed]  [image removed]
>
> [image removed]
>
> [image removed] [image removed] [image removed]
>
> [image removed]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20150427/6bb3f67c/attachment.html>