Re: Patch to fix SMB browsing bugs

[Nielsen <nielsen memberwebs com>]

Alexander Larsson wrote:
> Kerberos should already be supported, with a small patch to samba (which
> is in FC3):
> http://mail.gnome.org/archives/nautilus-list/2004-July/msg00154.html
>
> I haven't tested this extensively, but i did try it once against a AD
> domain. I did recently get a mail from some ibm people testing this
> though, and it seems that it might have some issues.

Wonderful, that's good news.

> > In addition it's a safe assumption that multiple shares on the same 
> > computer use the same user/password combinations. IMO, we should cache 
> > this for a single smb host, rather than per share as is currently the case.
>
> Yes. That makes sense. Unless the cached password fails on some share,
> then we should ask again.

Agreed.

> Saving the password in the keyring is nice for some things. However,
> many passwords you don't want to store like that (for security reasons
> perhaps). Gnome-vfs tends to have in-process caches for these things so
> they work without having to call out to the keyring all the time.

True. This needs work.

> Another way would be to store a smb context in thread-local storage.
> However, i'm not sure this is enough. You'd have to review all the samba
> code used by libsmbclient and verify that there are no global variables
> used. (Or at least no ones are modified after initialization.) I don't
> think this is true...

I checked and you're correct. Samba 3.x and its various libraries aren't 
threadsafe *or* reentrant in the least. Apparently this is something 
that's being worked on for samba 4.x.

I'm interested in getting this working and there are several approaches 
that could be taken to fixing the problem. I've given it a lot of 
thought. Unlikely solutions:

1. Waiting for the new libsmbclient code
   - IMO, too long to wait for stable SMB.
   - A nice solution later on down the road.

2. Include our own SMB or CIFS code into gnome-vfs, possibly from
   the kernel CIFS module.
   - Seems too hard to maintain.
   - Security bug fixes.

3. Fork extra processes for SMB access.
   - More indirection.
   - Performance hit due to more IPC.
   - Scary marshalling.
   - etc, etc...

Today I came across something else that we could try. Leave SMB network 
access inside the lock (which can't really be helped). However we could 
make sure to only call gnome-authentication stuff outside. Would work 
something like this:

1. Request comes in from gnome-vfs
2. Check our internal password cache. Possibly fill in a
   password for auth_fn to return.
3. Enter lock.
4. Call appropriate libsmbclient function.
4a. auth_fn may be called at this point, may return cached pw,
    or makes note of the server / share for which pw is needed.
5. Leave lock.
6. If libsmbclient returns EACCESS (or some such) we run the
   gnome-auth prompt, cache the pw, and loop back to [2].

Naturally we'd cancel on user request etc... It maybe a little more 
convoluted than the current code flow, but it may be more stable.

The only downside I can see is on initial connection to a server we'd 
have an invalid request (with zero length pw) going first. Hopefully a 
cache internal to gnome-vfs (as you spoke of above) would mitigate this 
problem.

Any thoughts?

Cheers,
Nate