[jcifs] Getting security Descriptors, problems with masks
madlg3 at vodafone.es
madlg3 at vodafone.es
Mon Dec 22 17:54:46 GMT 2003
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
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
> 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.
> 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