[jcifs] Re: Share permissions

[Michael B Allen]

There are no ACCESS_DENIED responses in the first capture.

There are two ACCESS_DENIED NT_CREATE_ANDX (aka open) responses
in the second capture. Each resource trying to be opened is the
share \\WXP-IE-65-201\DIR7SHARE. Each are immediately followed by
successful NT_CREATE_ANDX request/responses. The difference between
the ACCESS_DENIED responses and the corresponding successful one are
some access mask bits. In particular it looks like the "Write DAC" bit
is on in the failed request and turned off in the successful one. The
"Read Control" bit IS on for the successful requests which is to say
there is nothing terribly meaningful with regard to the ACCESS_DENIED
responses. It's returning ACCESS_DENIED because the client application
is trying to open the ACL for write and falling back to read only.

If you cannot figure out how to get the ACL using Windows theres no way
JCIFS will be able to so I'm not sure where you're going with this.

Mike

On Tue, 02 Jan 2007 12:27:18 -0500
Karl Wright <kwright at metacarta.com> 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
> 
> 
> 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
> >>>
> >>
> >>
> > 
> > 
> 
> 


-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/