samba.git/source3/smbd, branch master

s3/smbd: fix FSCTL_SET_SPARSE permission checks

2015-03-09T20:27:08+00:00

On Windows servers (tested against Windows Server 2008 & 2012) the
FSCTL_SET_SPARSE ioctl is processed if FILE_WRITE_DATA,
FILE_WRITE_ATTRIBUTES _or_ SEC_FILE_APPEND_DATA permissions are granted
on the open file-handle.
Fix Samba such that it matches this behaviour, rather than only checking
for FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES.

Signed-off-by: David Disseldorp 
Reviewed-by: Jeremy Allison

s3/statvfs: expose FILE_SUPPORTS_SPARSE_FILES capability

2015-03-09T20:27:07+00:00

Samba now supports:
- FSCTL_SET_SPARSE
- FSCTL_SET_ZERO_DATA, via FALLOC_FL_PUNCH_HOLE
- FSCTL_QUERY_ALLOCATED_RANGES, via SEEK_DATA/SEEK_HOLE

As such, flag support for sparse files, via the
FILE_SUPPORTS_SPARSE_FILES capability flag if FALLOC_FL_PUNCH_HOLE and
SEEK_DATA/SEEK_HOLE are present at configure time.

Signed-off-by: David Disseldorp 
Reviewed-by: Jeremy Allison

smbd/ioctl: add FSCTL_QUERY_ALLOCATED_RANGES support

2015-03-09T20:27:07+00:00

This change implements support for FSCTL_QUERY_ALLOCATED_RANGES using
the SEEK_HOLE/SEEK_DATA functionality of lseek().

Files marked non-sparse are always reported by the ioctl as fully
allocated, regardless of any potential "strict allocate = no" savings.

Signed-off-by: David Disseldorp 
Reviewed-by: Jeremy Allison

smbd/ioctl: add FSCTL_SET_ZERO_DATA support

2015-03-09T20:27:07+00:00

FSCTL_SET_ZERO_DATA can be used in two ways.
- When requested against a file marked as sparse, it provides a
  mechanism for requesting that the server deallocate the underlying
  disk space for the corresponding zeroed range.
- When requested against a non-sparse file, it indicates that the server
  should allocate and zero the corresponding range.

Both use cases can be handled in Samba using fallocate(). The Linux
specific FALLOC_FL_PUNCH_HOLE flag can be used to deallocate the
underlying disk space. After doing so, a normal fallocate() call can
be used to ensure that the zeroed range is allocated on non-sparse
files.

FSCTL_SET_ZERO_DATA requests must not result in a change to the file
size. The FSCTL_SET_ZERO_DATA handler always calls fallocate() with the
KEEP_SIZE flag set, ensuring that Samba meets this requirement.

Signed-off-by: David Disseldorp 
Reviewed-by: Jeremy Allison

s3/vfs: change fallocate mode flags from enum->uint32_t

2015-03-09T20:27:07+00:00

The Linux fallocate syscall offers a mode parameter which can take the
following flags:
FALLOC_FL_KEEP_SIZE
FALLOC_FL_PUNCH_HOLE (since 2.6.38)
FALLOC_FL_COLLAPSE_RANGE (since 3.15)
FALLOC_FL_ZERO_RANGE (since 3.14)

The flags are not exclusive, e.g. FALLOC_FL_PUNCH_HOLE must be specified
alongside FALLOC_FL_KEEP_SIZE.

Samba currently takes a vfs_fallocate_mode enum parameter for the VFS
fallocate hook, taking either an EXTEND_SIZE or KEEP_SIZE value. This
commit changes the fallocate hook such that it accepts a uint32_t flags
parameter, in preparation for PUNCH_HOLE and ZERO_RANGE support.

Signed-off-by: David Disseldorp 
Reviewed-by: Jeremy Allison

s3:smbprofile: Replace sysv shmem with tdb

2015-03-06T11:31:10+00:00

What?

This patch gets rid of the central shared memory segment referenced by
"profile_p". Instead, every smbd gets a static profile_area where it collects
profiling data. Once a second, every smbd writes this profiling data into a
record of its own in a "smbprofile.tdb". smbstatus -P does a tdb_traverse on this
database and sums up what it finds.

Why?

At least in my perception sysv IPC has not the best reputation on earth. The
code before this patch uses shmat(). Samba ages ago has developed a good
abstraction of shared memory: It's called tdb.

The main reason why I started this is that I have a request to become
more flexible with profiling data. Samba should be able to collect data
per share or per user, something which is almost impossible to do with
a fixed structure. My idea is to for example install a profile area per
share and every second marshall this into one tdb record indexed by share
name. smbstatus -P would then also collect the data and either aggregate
them or put them into individual per-share statistics. This flexibility
in the data model is not really possible with one fixed structure.

But isn't it slow?

Well, I don't think so. I can't really prove it, but I do believe that on large
boxes atomically incrementing a shared memory value for every SMB does show up
due to NUMA effects. With this patch the hot code path is completely
process-local. Once a second every smbd writes into a central tdb, this of
course does atomic operations. But it's once a second, not on every SMB2 read.

There's two places where I would like to improve things: With the current code
all smbds wake up once a second. With 10,000 potentially idle smbds this will
become noticable. That's why the current only starts the timer when something has
changed.

The second place is the tdb traverse: Right now traverse is blocking in the
sense that when it has to switch hash chains it will block. With mutexes, this
means a syscall. I have a traverse light in mind that works as follows: It
assumes a locked hash chain and then walks the complete chain in one run
without unlocking in between. This way the caller can do nonblocking locks in
the first round and only do blocking locks in a second round. Also, a lot of
syscall overhead will vanish. This way smbstatus -P will have almost zero
impact on normal operations.

Pair-Programmed-With: Stefan Metzmacher 

Signed-off-by: Volker Lendecke 
Signed-off-by: Stefan Metzmacher 
Reviewed-by: Ralph Boehme

smbd: Fix CID 1273088 Resource leak

2015-03-03T16:34:39+00:00

Signed-off-by: Volker Lendecke 
Reviewed-by: Ralph Boehme

smbd: Make SMB3 clients use encryption with "smb encrypt = auto"

2015-03-03T09:40:42+00:00

Signed-off-by: Volker Lendecke 
Reviewed-by: Stefan Metzmacher 

Autobuild-User(master): Volker Lendecke 
Autobuild-Date(master): Tue Mar  3 10:40:42 CET 2015 on sn-devel-104

MSDFS referral shuffling

2015-02-27T21:53:06+00:00

Shuffle MSDFS referral list in smbd in accordance with [MS-DFSC] 3.2.1.1
When parsing an MSDFS symlink, the names are shuffled with a Fisher-Yates
algorithm.

Signed-off-by: Robin McCorkell 
Reviewed-by: David Disseldorp 
Reviewed-by: Jeremy Allison

smbd: Simplify ReadDirName

2015-02-26T17:51:10+00:00

In the if-branches we return, so no "else" necessary

Signed-off-by: Volker Lendecke 
Reviewed-by: Jeremy Allison