[jcifs] Getting security Descriptors, problems with masks
madlg3 at vodafone.es
madlg3 at vodafone.es
Thu Dec 18 08:44:53 GMT 2003
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 )
This method sends a frame over the wire called SmbComNTCreateAndX. This
frame constructor contains two variables (desiredAccess and
createOptions) which will never contain the values needed to access
security information from a file. The idea should be to have the
possibility to specify the value of these two parameters.
Let´s see these problems in details.
The problem related to this parameter is that we need the createOptions
to have two possible values: 0x0040 for files and 0x0000 for folders,
if we have a folder we cannot open it with the value obtained in this
method. As it is now this parameter is only applicable to files. And we
are only granted to query for file SD, but not folders.
The 7th bit specifies a security check that does not allow a folder to
be opened. In order to open a folder to get its security information
this bit must be 0. So the default value 0x00040 is not valid. The OR
function within the method (this.createOptions = createOptions |
0x0040;) that modifies this parameter grants new features to be
checked, but only for files. There is no way to toggle this bit, so a
modification in the code is needed, distinguishing when the windows
object is a file or a directory.
Another problem is the desiredAccess parameter. This parameter should
contain a value containing the following mask accessFlag = 0x0012019f.
If this mask is not granted then no security descriptor can be gotten
from the file and no info about ACLs, users, groups etc can be
The bit called ReadControl(18th bit) is the most important. This is
needed to read ACLs owner information, etc. The hardcoded value of the
field desired access is not enough to access security information, it
only grants the first bits related to read the file and its extended
attributes. (desiredAccess |= FILE_READ_EA | FILE_READ_ATTRIBUTES;)
Are there any plans to modify that?
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.
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.
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.
I would like to have some feedback about these problems I found and if
there is a solution to them. This jcifs is a great library, it is
really good stuff I am really enjoying using it!
Miguel de Luna
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