Re: SMB error: "Sorry, couldn't display all the contents of..."

[y9toi7y02 sneakemail com]

On 3 Jun 2004, Alexander Larsson alexl-at-redhat.com |nautilus| wrote:

> On Thu, 2004-06-03 at 01:21, y9toi7y02 sneakemail com wrote:
> > If someone is going to work at it, could they please make it use the
> > settings from /etc/samba/smb.conf or /etc/smb.conf if there is no
> > ~/.smb/smb.conf? As of now, it creates and uses an empty copy in your
> > homedirectory while it is hard to come up with a reason to use a per user
> > config. This way it defaults to using broadcasting for browsing, which is
> > really slow while using WINS is instant. Also it doesn't work with
> > multiple subnets, tends to miss hosts, is really bad on the network
> > etcetera.
>
> Yeah. There are some things that we need to set though, such as filename
> encodings etc, that would break if we read the system smb.conf and used
> the (non-default) settings from there. Ideally we should read the system
> smb.conf and have some way in libsmbclient to override specific settings
> that we need.
Why wouldn't you want the system-wide config to contain the right filename
encoding too?
>
> > A quick inspection shows that the libsmbclient library forces this
> > though..
> >
> > Also allowing the samba kerberos stuff to be used would be great, as you
> > do not have to type your password anymore. There doesn't seem to be an
> > option in smb.conf for that, but you can pass -k to smbclient to use it.
>
> Yes. That would rule. I have no idea how this works though :)
>
> > Quick inspection of libsmbclient shows that it does not allow this too
> > though :(
Apparently libsmbclient is an abstraction over libsmb. Libsmbclient uses
its own contexts (called 'ctx' in the code), libsmb uses another kind of
context (called 'cli' in the code).

libsmbclient could just set cli->use_kerberos = 1 and it would work.
It's just that it doesn't do that.

>
> Another problem with libsmbclient is that it always tries to log in
> anonymous after the given user/password failed login, so if anon login
> works we can't actually give the user several tries to login, which
> sucks.
AFAIK Windows (2000 and XP) does this:

- Try kerberos if the server seems to support this and you have a
ticket (you have one if you are logged on to a domain)
- Try anonymous login
- Ask for a password and try NTLMv2 and NTLM login (plaintext login is
forbidden by default; you have to change the registry to allow it).

So if anonymous login is allowed you can't (without using tricks like the
'net' command or the 'map network drive' menu item) force login. I don't
expect a lot of smb servers to be setup so Windows clients do not work
with them.

Unfortunately unix users typically do not have kerberos tickets. That
means that you wouldn't be able to browse to shares that you have to be
logged in for to see. You can just type the share name and it would ask
for a password though.
>
> It would rock of some of the libsmbclient developers could work with us
> to make smb integration rock.
One thing to keep in mind is that this is an area in which Microsoft sets
the standards. Often it is best to look what they do and imitate them,
even if it doesn't seem to be the best way to do it. Most servers are set
up to work with Windows clients so if you do something they wouldn't, you
can easily find yourself out of luck. Convincing Windows administrators to
set up their servers to support (typically officially unsupported) samba
clients is not easy at all.

I would propose to use kerberos when the user has a ticket and default to
anonymous when they haven't or the ticket is not enough.

Note that you need to be really careful with sending and especially
caching logins because you can trivially spoof the server names. Using
broadcasts it's just a matter of who answers first, using WINS it's who
registers first.

This means that, if you allow plaintext logins, a malicious server can
easily get your credentials (that's why Windows forbids it by default).
NTLM was devised to deal with spoofed servers trying to steal your login
but the encryption is rather weak and allows for Man in the Middle
attacks. NTLMv2 allows the server to prove its identity so these attacks
are no longer possible and it upgrades the encryption, but you need
information about the domain the server is in for this to work.

This means that whatever way you use of caching the login and password is
rather insecure if your client does not have the domain information, and
samba never has it as it does not support being a domain member as a
client.

Using kerberos is the safest way because you only have to send the ticket
which is of very little value to an attacker, so you can afford to just
default to sending it to anyone who asks. Then again, this only works with
Windows 2000/XP or samba machines, that are in a domain (ADS mode for
samba).

Martijn Vernooij