[jcifs] Re: Share permissions

[Karl Wright]

Karl Wright wrote:
> Thanks, Mike.
> 
> I already sent the remote query to you (or, rather, a TCPDUMP of the 
> entire session where I opened the properties panel for the dir7share 
> from a remote Windows machine).  Windows *did* let me into the 
> "properties" panel, but before it did it said that I could not access 
> security for that share remotely, and when I got in sure enough the 
> security display was grey'd.  I've reattached them.  What interested me 
> was that you said that you saw "Access denied" in that dump for at least 
> one transaction.  If that transaction had anything to do with dir7share 
> I'd love to know which transaction that was, and what Windows seemed to 
> be asking for at that time.
> 
> Karl
> 

After looking at these with ethereal, I found two interesting issues in 
the tcpdump.out.2 trace, which is the one where I tried to access dir7share.

First, there's a protocol error!  Look for a SMB NT_Trans_Request packet 
that is a NT_QUERY_SECURITY_DESC request.  One of them comes back with 
"Buffer too small".  Not sure why Windows would fail in this way - 
although it could well be that there is a version difference between the 
client and the server.

Second, there's a NetrShareGetInfo request that goes out to 
wxp-ie-65-201 for dir7share.  Do you have any idea what this request 
might be for, and would Jcifs submit a similar request at any point?

Thanks again,
Karl

> 
> Michael B Allen wrote:
> 
>> Empty response:
>>
>> NtTransQuerySecurityResponse[command=SMB_COM_NT_TRANSACT,received=false,errorCode=0,flags=0x0098,flags2=0xC003,signSeq=0,tid=2048,pid=40463,uid=2048,mid=8,wordCount=18,byteCount=25,totalParameterCount=4,totalDataCount=20,parameterCount=4,parameterOffset=72,parameterDisplacement=0,dataCount=20,dataOffset=76,dataDisplacement=0,setupCount=0,pad=1,pad1=0] 
>>
>>
>> Not much JCIFS can do about that.
>>
>> If you recall we tried to get a capture of Windows acquiring the security
>> descriptor on the errant share but you could not get it remotely due to
>> the associated ACL editor dialogs being grey'd out (or something like
>> that). If you can get a capture of a remote query of the share's ACL
>> I'd be happy to look. Otherwise, when I run the GetSecurity example an
>> a share in my environment it is successful. So there must me something
>> special about the shares you're using.
>>
>> Also, you might consider directing some of these questions through
>> the JCIFS mailing list. Someone else may have an explaination for the
>> behavior.
>>
>> Mike
>>
>> On Tue, 02 Jan 2007 09:24:04 -0500
>> Karl Wright <kwright at metacarta.com> wrote:
>>
>>
>>> Hi Michael,
>>>
>>> I hope you had a restful vacation.
>>>
>>> I still have not figured out what the issue is fundamentally with the 
>>> share permissions for the test case that is failing for me.  Just to 
>>> recap, there's a share which does not seem to permit its security to 
>>> be examined by a remote Windows machine, but when I query the share's 
>>> security using jCifs I get back no SIDs at all, and no exception 
>>> either.  I'd like to figure out what's happening, and what I need to 
>>> do to behave in a manner similar to what Windows does.
>>>
>>> The test in question requests information for dir7share (which is the 
>>> share) and for dir7share/7 (which is a file).
>>>
>>> I've attached two logs.  The first (agents_out.log) is a standard-out 
>>> log made with jcifs debugging level set to 10.  The second 
>>> (agents.log) is my crawler's log, which simply shows that I get back 
>>> zero SIDs for dir7share.
>>>
>>> I did not see any "access is denied" responses in here anywhere, nor 
>>> do I see NTSECURITY requests, so I presume they are not specially 
>>> noted in the debug output.  Can you confirm that the security request 
>>> for dir7share simply returns no SIDs, and does not indicate an 
>>> error?  If so, I'd love to compare against the Windows interaction 
>>> TCPDUMP captures I sent back in December to see what the difference is.
>>>
>>> Thanks,
>>> Karl
>>>
>>>
>>> Michael B Allen wrote:
>>>
>>>> On Fri, 22 Dec 2006 22:57:37 -0500
>>>> Karl Wright <kwright at metacarta.com> wrote:
>>>>
>>>>
>>>>
>>>>> Michael B Allen wrote:
>>>>>
>>>>>
>>>>>> On Fri, 22 Dec 2006 22:21:41 -0500
>>>>>> Karl Wright <kwright at metacarta.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> All of the NT_QUERY_SECURITY_DESC calls are still clearly not 
>>>>>>>> returning
>>>>>>>> ACLs. It's either empty or the response is ACCESS_DENIED. But if 
>>>>>>>> you
>>>>>>>> never really saw the ACLs in the ACL editor I guess this is no 
>>>>>>>> surprise.
>>>>>>>>
>>>>>>>
>>>>>>> For the ACCESS_DENIED responses, what will JCifs return?
>>>>>>> Karl
>>>>>>
>>>>>>
>>>>>>
>>>>>> It should throw an SmbAuthException with text "Access denied" but 
>>>>>> you'll
>>>>>> want to confirm that as there might be some logic that prevents it.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>
>>>>> I don't seem to get that for the "access denied" share.  It seems 
>>>>> to return an empty ACE array instead.  I'll try to turn on debug 
>>>>> for JCifs next.  Where exactly do I do that?
>>>>
>>>>
>>>>
>>>> There were also instances where the NT_QUERY_SECURITY_DESC returned
>>>> successfully but with no ACEs in which will result in an empty ACE[]
>>>> array. You have to be prepared to deal with both cases (at least).
>>>>
>>>> See the API overview page for the jcifs.util.loglevel property.
>>>>
>>>> Mike
>>>>
>>>
>>>
>>
>>