[jcifs] Problem with guest user access

[Eric Rotick]

On Mon, 10 Jan 2005 21:18:30 -0500 (EST), Michael B Allen
<mba2000 at ioplex.com> wrote:
> Eric Rotick said:
> > From my experience the current implementation is already a source of
> > considerable confusion and here's why.
> >
> > The application was developed and everything was tested and shown to
> > be working to spec. This was then deployed and ran for several months
> > without any problem. The Samba server of one of the clients then
> > decided to create a new user for some new service. Still all OK. The
> > sysadmin then decided that this new service was not regarded as secure
> > by any means and so set the quest account directive to that user. The
> > application then broke.
> 
> Ahh, so you really can set what user Samba considers 'guest'. Odd.
> 
> > We tested everything again and also setup a guest account but we used
> > the default username guest for this and so everything worked for us.
> > The next thing was to look at the source and, bingo, there's the
> > problem. A quick change to the source to prove the theory and we're
> > back in business.
> >
> > I would humbly suggest that the current implementation is inconsistent
> > in that when the server side changes the guest user to be anything
> > other than "guest" the client side will fail unless the username is
> > also "guest". The Samba docs say that guest is used to mark a service
> > as not requiring a password. It doesn't say that guest must also be
> > used as the username.
> 
> Well, you have to realize that the jCIFS and Samba projects are really
> separate entities. JCIFS tries to be compliant with generally accepted
> CIFS protocol practices. Being able to change which username is considered
> to be 'guest' is not a standard feature. At least I've never heard of it
> until now.
> 
> It doesn't matter though because the whole concept of logging someone in
> as "guest" if their authentication fails is explicitly NOT supported in
> JCIFS. If the username is "guest" then we permit it but otherwise our
> internal structures are immutible so it's very difficult to support such a
> feature.
> 
> > When the Jsifs application is configured a username and password is
> > used to access any number of services. That application would then
> > need to know that the server side has changed a service to be guest.
> > Surely that's a server side decision only and not something which
> > should be reflected in the client.
> 
> CIFS as a protocol does not support changing the username that the server
> considers to be 'guest'. That is apparently a Samba-ism.
> 
> > Having removed the code in SmbSession everything now works as we would
> > expect. Is there some behaviour which is broken as a result of this?
> 
> I don't understand the question but if you simply remove the three lines
> in SmbSession that check for guest then the client will behave as you
> expect. Note however that if you then do 'file.getPrincipal().getName()'
> the name will not be "guest" or whatever the username is that is
> considered on the server to be guest. It will be the username specified in
> the NtlmPasswordAuthentication object originally used to construct the
> file. And that is ultimately why we do not support the concept of
> defaulting to different credentials (e.g. guest) than the ones supplied.
> 
> Mike
> 

I am happy that jCIFS and Samba are distinct projects and I am
certainly not suggesting that there should be any change to the
protocol. However, it is my suggestion that the current implementation
is incorrect and leads to considerable confusion. My earlier post was
to clarify if the change I made resulted in something else breaking
that I am not aware of.

Now that you are aware that the 'guest' username can be changed, at
least with Samba , I can explain further why I think the
implementation is wrong.

Consider the Windows user fred with password bloggs. This user is
authorised to connect to many servers and many services with the same
username and password. If one of those services is deemed to allow
guest access then the current implementation forces the user to change
the username to be guest to access that service. This is not the case
for a Windows client.

The choice of making a service to allow guest access is a server side
one and the current implementation is forcing that change back to the
client.

Now consider an application using jCIFS. This application collects
information from a series of Samba servers which belong to many
different customers. The username and password details for that
application are allocated on a per customer basis and are used for
other applications as well. If one of those services is setup to allow
guest access then there are some changes to be made as well as
debugging the application because the effect is hidden.

If I make a 'file.getPrincipal().getName()' call then I would expect
the application to return fred since that is what was supplied for
authentication. If anything, maybe there shoud be another method like
'isGuestAccess( )'.

In summary, can I request that the lines in SmbSession be removed for
the reasons outlined above.

Eric.