From: Jeremy Allison <jra@samba.org>
To: "Steve French (IBM LTC)" <smfltc@us.ibm.com>
Cc: linux-cifs-client@lists.samba.org, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-cifs-client] re: Problem with CIFS
Date: Wed, 18 Aug 2004 16:02:11 -0700 [thread overview]
Message-ID: <20040818230211.GD8700@legion.cup.hp.com> (raw)
In-Reply-To: <41247C40.5DB76262@us.ibm.com>
On Thu, Aug 19, 2004 at 05:09:04AM -0500, Steve French (IBM LTC) wrote:
>
> This is caused by an interesting bug in Samba, but one I should be able to
> workaround. Basically Samba is setting a flag in the negotiate response saying
> "I support extended security"
> which indicates that this frame should be decoded as if it contained an SPNEGO blob
> (ala RFC 2478) and a conflicting capability in the same frame which indicates
> "I am not capable of extended security"
> The Samba server sets this SMB_FLAGS2_EXTENDED_SECURITY in the response even though
> the client said - no extended security (Windows gets this right).
> ....
> The Samba fix is pretty easy as well (it only hits source/smbd/negprot.c -
> reply_negprot function), I will bounce the fix off jra before updating the Samba 3
> source.
Can you show me where the problem is ? Currently in smbd/negprot.c we have :
/* do spnego in user level security if the client
supports it and we can do encrypted passwords */
if (global_encrypted_passwords_negotiated &&
(lp_security() != SEC_SHARE) &&
lp_use_spnego() &&
(SVAL(inbuf, smb_flg2) & FLAGS2_EXTENDED_SECURITY)) {
negotiate_spnego = True;
capabilities |= CAP_EXTENDED_SECURITY;
}
Which I thought should be correct.
Cheers,
Jeremy.
prev parent reply other threads:[~2004-08-18 23:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040818120033.9DD101638C1@lists.samba.org>
2004-08-19 10:09 ` Problem with CIFS Steve French (IBM LTC)
2004-08-18 23:02 ` Jeremy Allison [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040818230211.GD8700@legion.cup.hp.com \
--to=jra@samba.org \
--cc=akpm@osdl.org \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smfltc@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox