Re: [PATCH] SMB user/password caching across shares

[Alexander Larsson <alexl redhat com>]

On Wed, 2005-01-26 at 22:57 +0000, Nielsen wrote:
> Alexander Larsson wrote:
> > I commited this to get it into todays release (we're even more frozen
> > after that). 
> 
> I committed a fix to the initial_authenication code today. My revised 
> patch didn't use the open connection cache unless there was a user name 
> specified in the URI, obviously not a good situation.

Yes, that was what i was thinking of. However, I still have this nagging
feeling that something can go wrong.

There is an invariant I want to hold. Something like:
"If i access a specific server/share and get a user/password dialog, all
further accesses to that specific server/share should use the same user
until i get a new login dialog".

In particular, if i open a file on a server/share, keeping it opened
(reading a large file, say) and then in parallel with this i open
another (or the same) file the second open must use the same credentials
to check whether the file open is allowed.

I have a feeling that update_user_cache() which gets called on any
successful login (for both the server and server+share) can somehow
cause this to be broken.

Here are some examples of how this could happen:

example A: 
1) smb://server/share is accessed, user logs in as user1
   default user for "server" and "server/share" is now user1
2) smb://user2 server/share is accessed. The default user lookup fails.
   password dialog again, and user2 logs in. In save_authentication() we
   update the default user for "server" and "server/share" to user2.
3) another access to smb://server/share happens. Maybe parallel to the
   first one, or right after it. However, lookup_user_cache now finds
   user2 for this, and uses different credentials. It might even get the
   cached connection from 2).

example B:
1) smb://server/share is accessed. log in as user1
   start download of large file, meaning the connection to the
   server is not free for a long time
   default user for server and server/share is now user1
2) smb://server/othershare is accessed, user1 login fails, user
   logs in (via dialog) as user2. Default for server and
   server/usershare2 is now user2.
3) the cache reaper jumps in and reaps the server/share default
   (not the other one, since its newer)
4) another access to smb://server/share, now gets user2 as the
   default user, even though there is an ongoing access to server/share
   as user1.

example C:
Same as example B, but the access in 1) is of normal length. Would you
expect the access in 4) to use the credentials of user2?

Its possible the examples are a bit contrived, but especially example C
strikes me as a bit surprising.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a scrappy Amish cop in drag. She's a mentally unstable wisecracking 
mechanic who don't take no shit from nobody. They fight crime!