[jcifs] Getting security Descriptors, problems with masks

madlg3 at vodafone.es madlg3 at vodafone.es
Mon Dec 22 17:54:46 GMT 2003

Hi Michael,

Thanks for the reply. I checked jcifs 0,8b but I cannot see a solution 
to my problems. Specially the createOptions parameter. It must have a 
value that it is not possible with createOption = createOptions|0x040. 
THe value must host the value 0 in this bit set to 1 to query on 
files.In the value of CreateOptions == 0x0040 I cannot open folders. 

Regarding the refresh, it would be enough with calling open again, you 
are right.

Thanks for the support,


p.d: I will try to upload the code somewhere. At the moment the first 
realease of my library to query for windows security is finished.

----- Mensaje Original -----
De: "Michael B Allen" <mba2000 at ioplex.com>
Fecha: Viernes, Diciembre 19, 2003 9:57 am
Asunto: Re: [jcifs] Getting security Descriptors, problems with masks

> >
> > Hi,
> Hi Miguel,
> >
> > I have developed several new frames in order to get the security
> > descriptor from Windos files. After I get this security 
> descriptor I
> > need to access several Windows pipes in order to get groups, 
> names from
> > sids and so on. I am using Jcifs as transport mechanism, more 
> exactly> SmbPipes. I have found some problems I would like you to 
> ask about them
> > to know if there is a workaround or if there is a different way 
> to do
> > them than modifying the code directly.
> >
> >
> > First problem arises in the open method in the SmbFile class:
> >
> > •	void open( int flags )
> > CreateOptions parameter
> > DesiredAccess parameter
> > The bit  called ReadControl(18th bit)
> >
> > Are there any plans to modify that?
> Please look at 0.8b. There have been some changes regarding 
> opening files with different
> parameters. I think you will see the trend is to externalize those 
> parameters. They
> really  should not be hard coded.
> > Another issue is the fid parameter within SMBfile
> > The fid parameter is very important when querying for security 
> info and
> > is one of the parameters to be sent over the wire. This fid must be
> > refreshed before creating the frame that gets the security by 
> means of
> > calling the open method inherited from the SmbFile(Thinking that 
> we are
> > sending this frame from a class derived from SmbFile). If this 
> is not
> > done, then remote null pointer exceptions are fired, due to a non
> > longer valid fid. The same applies when the file is 
> disconnected, the
> > fid should be liberated in order to avoid memory problems in the 
> remote> computer, if files are not close there is a moment where 
> nothing works.
> > When the file is no longer needed a close is needed.Therefore it 
> would> be nice to have a method called “refresh” that calls the 
> open method in
> > the SmbFile prior to the formation of this frame, passing a 
> fresh fid
> > into the frame constructor. If there is no call, made to the open
> > method before sending this frame over the wire, the protocol 
> > sometimes with error responses.
> I believe you mean that if a file should be opened with certain 
> access parameters but
> later more access is required, the existing fid is not suitable? 
> In this case it is
> necessary to simply open the file again. This is done in 0.8b when 
> certain write
> permissions are required to set attributes and timestamps. The 
> file is opened and closed
> immediately thereafter in that case. Again, please review the new 
> code as I believe it
> pertains to your interests.
> > DCE Implementation using jcifs smbPipes
> >
> > The problem here comes from the fact that we use SmbPipes as 
> mean of
> > transportation with the remote system. In order to get information
> > related to user, groups and so on we have to open different 
> pipes in
> > the remote system, and then we send the dce frames to get the info.
> > These pipes will be used in bidirectional way, sending request and
> > receiving responses. The smbPipes rely on the SmbFile (in fact 
> SmbPipe> inherits from SmbFile) and DCE frames rely on smbPipes. 
> The use of
> > these smbPipes raises another problem .SmbPipes extends from 
> > and therefore it extends all the limitations explained before .A 
> remote> pipe cannot be open with the hardcoded desiredaccess 
> parameter. This is
> > clear due to the security concerns related to query NT pipes. 
> Thus we
> > need a little modification in this part, it must extend from a 
> > similar to smbFile but with no problem to specify access. Then 
> we would
> > need a constructor similar to  public SmbNamedPipe( String url, int
> > pipeType,int aFlags ), where aFlags indicates in which way we 
> desire to
> > open the pipe. With the current implementation there is no way to
> > connect to a security pipe like SARM or LSAR. The easy solution 
> to this
> > derives from the solution of the first problems, if SmbFile 
> would allow
> > to specify these parameters then we won´t need to modify the 
> SmbPipes> as provided in Jcifs.
> A DCE RPC implementation has recently been released. It is called 
> Jarapac. See the link
> on our website. I am currently working on Jarapac in anticipation 
> of using it for jCIFS
> functionality that requires RPCs such as the LSA functions you're 
> interested in.
> However, the NDR encoding/decoding routines in Jarapac are 
> incorrect. I have just
> written an IDL compiler and I am very close to generating NDR from 
> IDL files from
> Samba4. From the generated stubs, Jarapac, and jCIFS transact 
> named pipes it will soon
> be possible to resolve sids, enumerate domains, reboot machines, 
> and much much more.
> > Currently I have a working version of some functions like getting
> > security descriptors, querying for groups, domains, sid, etc, 
> basically> all operations to interpret the bunch of bytes gotten 
> when querying for
> > the security descriptor, but I am still testing and improving 
> things.
> Great. Put the code somewhere and post a link. Try to think about 
> how you can make
> changes that are consistent with the changes made in 0.8b.
> >
> > I would like to have some feedback about these problems I found 
> and if
> > there is a solution to them.
> There certainly are solutions to these problems and I believe some 
> of the topics are
> covered in the changes for 0.8b. Also check out Jarapac if you get 
> a chance.
> > This jcifs is a great library, it is
> > really good stuff I am really enjoying using it!
> I agree! I am very exited about exposing Microsoft's network 
> management functionality to
> the Java world. It should lead to some very interesting products.
> Mike
> --
> A program should be written to  model the concepts of the task it
> performs rather than the physical world or a process because this
> maximizes the  potential for it  to be applied  to tasks that are
> conceptually similar and, more  important, to tasks that have not
> yet been conceived.

 Con Vodafone Mail puedes gestionar todos tus mensajes de correo 
electrónico, faxes, SMS y mensajes de voz de una forma cómoda y sin 
cuotas. Actívalo ya en http://www.vodafone.es/vodafonemail 

More information about the jcifs mailing list