[jcifs] Getting security Descriptors, problems with masks

[Michael B Allen]

>
> 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 answers
> 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 SmbFile
> 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 class
> 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.