When mounting with smb2 (or smb2.1 or smb3) we need to check to make
sure that attempts to query or set extended attributes do not
attempt to send the request with the older cifs protocol instead
(eventually we also need to add the support in SMB2
to query/set extended attributes but this patch prevents us from
using the wrong protocol for extended attribute operations).
Signed-off-by: NSteve French <smfrench@gmail.com>

Add a new protocol ops function create_mf_symlink and have
create_mf_symlink() use it.

This patchset moves the MFSymlink operations completely to the
ops structure so that we only use the right protocol versions when
querying or creating MFSymlinks.
Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

Rename open_query_close_cifs_symlink to cifs_query_mf_symlink() to make
the name more consistent with other protocol version specific functions.

We also pass tcon as an argument to the function. This is already
available in the calling functions and we can avoid having to make an
unnecessary lookup.
Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

When we are running SMB3 or SMB3.02 connections which are signed
we need to validate the protocol negotiation information,
to ensure that the negotiate protocol response was not tampered with.

Add the missing FSCTL which is sent at mount time (immediately after
the SMB3 Tree Connect) to validate that the capabilities match
what we think the server sent.

"Secure dialect negotiation is introduced in SMB3 to protect against
man-in-the-middle attempt to downgrade dialect negotiation.
The idea is to prevent an eavesdropper from downgrading the initially
negotiated dialect and capabilities between the client and the server."

For more explanation see 2.2.31.4 of MS-SMB2 or
http://blogs.msdn.com/b/openspecification/archive/2012/06/28/smb3-secure-dialect-negotiation.aspxReviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

Patch 2 of the copy chunk series (the final patch will
use these to handle copies of files larger than the chunk size.

We set the same defaults that Windows and Samba expect for
CopyChunk.
Signed-off-by: NSteve French <smfrench@gmail.com>
Reviewed-by: NDavid Disseldorp <ddiss@samba.org>

This first patch adds the ability for us to do a server side copy
(ie fast copy offloaded to the server to perform, aka refcopy)

"cp --reflink"

of one file to another located on the same server.  This
is much faster than traditional copy (which requires
reading and writing over the network and extra
memcpys).

This first version is not going to be copy
files larger than about 1MB (to Samba) until I add
support for multiple chunks and for autoconfiguring
the chunksize.

It includes:
1) processing of the ioctl
2) marshalling and sending the SMB2/SMB3 fsctl over the network
3) simple parsing of the response

It does not include yet (these will be in followon patches to come soon):
1) support for multiple chunks
2) support for autoconfiguring and remembering the chunksize
3) Support for the older style copychunk which Samba 4.1 server supports
(because this requires write permission on the target file, which
cp does not give you, apparently per-posix).  This may require
a distinct tool (other than cp) and other ioctl to implement.
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

Now we treat any reparse point as a symbolic link and map it to a Unix
one that is not true in a common case due to many reparse point types
supported by SMB servers.

Distinguish reparse point types into two groups:
1) that can be accessed directly through a reparse point
(junctions, deduplicated files, NFS symlinks);
2) that need to be processed manually (Windows symbolic links, DFS);

and map only Windows symbolic links to Unix ones.

Cc: <stable@vger.kernel.org>
Acked-by: NJeff Layton <jlayton@redhat.com>
Reported-and-tested-by: NJoao Correia <joaomiguelcorreia@gmail.com>
Signed-off-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

In SMB3 it is now possible to query the file system
alignment info, and the preferred (for performance)
sector size and whether the underlying disk
has no seek penalty (like SSD).

Query this information at mount time for SMB3,
and make it visible in /proc/fs/cifs/DebugData
for debugging purposes.

This alignment information and preferred sector
size info will be helpful for the copy offload
patches to setup the right chunks in the CopyChunk
requests.   Presumably the knowledge that the
underlying disk is SSD could also help us
make better readahead and writebehind
decisions (something to look at in the future).
Signed-off-by: NSteve French <smfrench@gmail.com>

The multiplex identifier (MID) in the SMB header is only
ever used by the client, in conjunction with PID, to match responses
from the server. As such, the endianess of the MID is not important.
However, When tracing packet sequences on the wire, protocol analyzers
such as wireshark display MID as little endian. It is much more informative
for the on-the-wire MID sequences to match debug information emitted by the
CIFS driver.  Therefore, one should write and read MID in the SMB header
assuming it is always little endian.

Observed from wireshark during the protocol negotiation
and session setup:

        Multiplex ID: 256
        Multiplex ID: 256
        Multiplex ID: 512
        Multiplex ID: 512
        Multiplex ID: 768
        Multiplex ID: 768

After this patch on-the-wire MID values begin at 1 and increase monotonically.

Introduce get_next_mid64() for the internal consumers that use the full 64 bit
multiplex identifier.

Introduce the helpers get_mid() and compare_mid() to make the endian
translation clear.
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NTim Gardner <timg@tpi.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

Allow cifs/smb2/smb3 to return whether or not a file is compressed
via lsattr, and allow SMB2/SMB3 to set the per-file compression
flag ("chattr +c filename" on an smb3 mount).

Windows users often set the compressed flag (it can be
done from the desktop and file manager).  David Disseldorp
has patches to Samba server to support this (at least on btrfs)
which are complementary to this
Signed-off-by: NSteve French <smfrench@gmail.com>

Since we don't get info about the number of links from the readdir
linfo levels, stat() will return 0 for st_nlink, and in particular,
samba re-exported shares will show directories as files (as samba is
keying off st_nlink before evaluating how to set the dos modebits)
when doing a dir or ls.

Copy nlink to the inode, unless it wasn't provided.  Provide
sane values if we don't have an existing one and none was provided.
Signed-off-by: NJim McDonough <jmcd@samba.org>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NDavid Disseldorp <ddiss@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

Currently, we try to ensure that we use vcnum of 0 on the first
established session on a connection and then try to use a different
vcnum on each session after that.

This is a little odd, since there's no real reason to use a different
vcnum for each SMB session. I can only assume there was some confusion
between SMB sessions and VCs. That's somewhat understandable since they
both get created during SESSION_SETUP, but the documentation indicates
that they are really orthogonal. The comment on max_vcs in particular
looks quite misguided. An SMB session is already uniquely identified
by the SMB UID value -- there's no need to again uniquely ID with a
VC.

Furthermore, a vcnum of 0 is a cue to the server that it should release
any resources that were previously held by the client. This sounds like
a good thing, until you consider that:

a) it totally ignores the fact that other programs on the box (e.g.
smbclient) might have connections established to the server. Using a
vcnum of 0 causes them to get kicked off.

b) it causes problems with NAT. If several clients are connected to the
same server via the same NAT'ed address, whenever one connects to the
server it kicks off all the others, which then reconnect and kick off
the first one...ad nauseum.

I don't see any reason to ignore the advice in "Implementing CIFS" which
has a comprehensive treatment of virtual circuits. In there, it states
"...and contrary to the specs the client should always use a VcNumber of
one, never zero."

Have the client just use a hardcoded vcnum of 1, and stop abusing the
special behavior of vcnum 0.
Reported-by: NSauron99@gmx.de <sauron99@gmx.de>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NVolker Lendecke <vl@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

that force a client to purge cache pages when a server requests it.
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

to make adding new types of lease buffers easier.
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

and separate smb20_operations struct.
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

that prepare the code to handle different types of SMB2 leases.
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

    Switch smb2 code to use per session session key and smb3 code to
    use per session signing key instead of per connection key to
    generate signatures.

    For that, we need to find a session to fetch the session key to
    generate signature to match for every request and response packet.

    We also forgo checking signature for a session setup response
    from the server.
Acked-by: NJeff Layton <jlayton@samba.org>
Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

Add a variable specific to NTLMSSP authentication to determine
whether to exchange keys during negotiation and authentication phases.

Since session key for smb1 is per smb connection, once a very first
sesion is established, there is no need for key exchange during
subsequent session setups. As a result, smb1 session setup code sets this
variable as false.

Since session key for smb2 and smb3 is per smb connection, we need to
exchange keys to generate session key for every sesion being established.
As a result, smb2/3 session setup code sets this variable as true.
Acked-by: NJeff Layton <jlayton@samba.org>
Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

MAX_SERVER_SIZE has been moved to cifs_mount.h and renamed
CIFS_NI_MAXHOST for clarity.  It has been expanded to 1024 as the
previous value of 16 was very short.
Signed-off-by: NScott Lovenberg <scott.lovenberg@gmail.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

The max string length definitions for user name, domain name, password,
and share name have been moved into their own header file in uapi so the
mount helper can use autoconf to define them instead of keeping the
kernel side and userland side definitions in sync manually.  The names
have also been standardized with a "CIFS" prefix and "LEN" suffix.
Signed-off-by: NScott Lovenberg <scott.lovenberg@gmail.com>
Reviewed-by: NChen Gang <gang.chen@asianux.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

that allows to access files through symlink created on a server.
Acked-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

When use of symlinks is enabled (mounting with mfsymlinks option) to
non-Samba servers, we always tried to use cifs, even when we
were mounted with SMB2 or SMB3, which causes the server to drop the
network connection.

This patch separates out the protocol specific operations for cifs from
the code which recognizes symlinks, and fixes the problem where
with SMB2 mounts we attempt cifs operations to open and read
symlinks.  The next patch will add support for SMB2 for opening
and reading symlinks.  Additional followon patches will address
the similar problem creating symlinks.
Signed-off-by: NSteve French <smfrench@gmail.com>

For cifs_set_cifscreds() in "fs/cifs/connect.c", 'desc' buffer length
is 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses->domainName'
length may be "255 + '\0'".

The related sprintf() may cause memory overflow, so need extend related
buffer enough to hold all things.

It is also necessary to be sure of 'ses->domainName' must be less than
256, and define the related macro instead of hard code number '256'.
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
Reviewed-by: NScott Lovenberg <scott.lovenberg@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NSteve French <smfrench@gmail.com>

On reconnects, we need to reopen file and then obtain all byte-range
locks held by the client. SMB2 protocol provides feature to make
this process atomic by reconnecting to the same file handle
with all it's byte-range locks. This patch adds this capability
for SMB2 shares.
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteven French <steven@steven-GA-970A-DS3.(none)>

and pass it to the open() call.
Signed-off-by: NPavel Shilovsky <pshilovsky@samba.org>
Signed-off-by: NSteven French <steven@steven-GA-970A-DS3.(none)>

Commit 9ddec561 (cifs: move handling of signed connections into
separate function) broke signing on SMB2/3 connections. While the code
to enable signing on the connections was very similar between the two,
the bits that get set in the sec_mode are different.

Declare a couple of new smb_version_values fields and set them
appropriately for SMB1 and SMB2/3. Then change cifs_enable_signing to
use those instead.
Reported-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Tested-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

Fix build warning in Shirish's recent SMB3 signing patch
which occurs when SMB2 support is disabled in Kconfig.

fs/built-in.o: In function `cifs_setup_session':
>> (.text+0xa1767): undefined reference to `generate_smb3signingkey'

Pointed out by: automated 0-DAY kernel build testing backend
Intel Open Source Technology Center

CC: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

SMB3 uses a much faster method of signing (which is also better in other ways),
AES-CMAC.  With the kernel now supporting AES-CMAC since last release, we
are overdue to allow SMB3 signing (today only CIFS and SMB2 and SMB2.1,
but not SMB3 and SMB3.1 can sign) - and we need this also for checking
secure negotation and also per-share encryption (two other new SMB3 features
which we need to implement).

This patch needs some work in a few areas - for example we need to
move signing for SMB2/SMB3 from per-socket to per-user (we may be able to
use the "nosharesock" mount option in the interim for the multiuser case),
and Shirish found a bug in the earlier authentication overhaul
(setting signing flags properly) - but those can be done in followon
patches.
Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

SMB3 protocol adds various optional per-share capabilities (and
SMB3.02 adds one more beyond that).  Add ability to dump
(/proc/fs/cifs/DebugData) the share capabilities and share flags to
improve debugging.
Signed-off-by: NSteve French <smfrench@gmail.com>
Acked-by: NJeff Layton <jlayton@redhat.com>

The new Windows update supports SMB3.02 dialect, a minor update to SMB3.
This patch adds support for mounting with vers=3.02
Signed-off-by: NSteve French <smfrench@gmail.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>

Before this patchset, the global_secflags could only offer up a single
sectype. With the new set though we have the ability to allow different
sectypes since we sort out the one to use after talking to the server.

Change the global_secflags to allow NTLMSSP or NTLMv2 by default. If the
server sets the extended security bit in the Negotiate response, then
we'll use NTLMSSP. If it doesn't then we'll use raw NTLMv2. Mounting a
LANMAN server will still require a sec= option by default.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

Now that we track what sort of NEGOTIATE response was received, stop
mandating that every session on a socket use the same type of auth.

Push that decision out into the session setup code, and make the sectype
a per-session property. This should allow us to mix multiple sectypes on
a socket as long as they are compatible with the NEGOTIATE response.

With this too, we can now eliminate the ses->secFlg field since that
info is redundant and harder to work with than a securityEnum.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Acked-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

Currently, we determine this according to flags in the sec_mode, flags
in the global_secflags and via other methods. That makes the semantics
very hard to follow and there are corner cases where we don't handle
this correctly.

Add a new bool to the TCP_Server_Info that acts as a simple flag to tell
us whether signing is enabled on this connection or not, and fix up the
places that need to determine this to use that flag.

This is a bit weird for the SMB2 case, where signing is per-session.
SMB2 needs work in this area already though. The existing SMB2 code has
similar logic to what we're using here, so there should be no real
change in behavior. These changes should make it easier to implement
per-session signing in the future though.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

We have this to some degree already in secFlgs, but those get "or'ed" so
there's no way to know what the last option requested was. Add new fields
that will eventually supercede the secFlgs field in the cifs_ses.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

Currently we have the overrideSecFlg field, but it's quite cumbersome
to work with. Add some new fields that will eventually supercede it.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>

Track what sort of NEGOTIATE response we get from the server, as that
will govern what sort of authentication types this socket will support.

There are three possibilities:

LANMAN: server sent legacy LANMAN-type response

UNENCAP: server sent a newer-style response, but extended security bit
wasn't set. This socket will only support unencapsulated auth types.

EXTENDED: server sent a newer-style response with the extended security
bit set. This is necessary to support krb5 and ntlmssp auth types.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

Add a new securityEnum value to cover the case where a sec= option
was not explicitly set.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>

This field is completely unused:

CIFS_SES_W9X is completely unused. CIFS_SES_LANMAN and CIFS_SES_OS2
are set but never checked. CIFS_SES_NT4 is checked, but never set.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Acked-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <sfrench@us.ibm.com>

The field that held this was removed quite some time ago.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Acked-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <sfrench@us.ibm.com>