Hello community,
here is the log from the commit of package cifs-utils for openSUSE:Factory
checked in at 2017-05-20 14:31:54
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/cifs-utils (Old)
and /work/SRC/openSUSE:Factory/.cifs-utils.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "cifs-utils"
Sat May 20 14:31:54 2017 rev:52 rq:495619 version:6.5
Changes:
--------
--- /work/SRC/openSUSE:Factory/cifs-utils/cifs-utils.changes 2017-03-18
20:49:22.467875156 +0100
+++ /work/SRC/openSUSE:Factory/.cifs-utils.new/cifs-utils.changes
2017-05-20 14:31:57.362236923 +0200
@@ -1,0 +2,7 @@
+Thu Apr 27 10:41:50 UTC 2017 - aap...@suse.com
+
+- Document SMB3+ and new seal option; (fate#322075).
+ + add patch 0001-manpage-correct-typos-and-spelling-mistakes.patch
+ + add patch 0002-mount.cifs-document-SMBv3.1.1-and-new-seal-option.patch
+
+-------------------------------------------------------------------
New:
----
0001-manpage-correct-typos-and-spelling-mistakes.patch
0002-mount.cifs-document-SMBv3.1.1-and-new-seal-option.patch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ cifs-utils.spec ++++++
--- /var/tmp/diff_new_pack.jgZTnm/_old 2017-05-20 14:31:58.282106781 +0200
+++ /var/tmp/diff_new_pack.jgZTnm/_new 2017-05-20 14:31:58.282106781 +0200
@@ -35,6 +35,10 @@
%endif
Source1: cifs.init
+# fate#322075
+Patch0: 0001-manpage-correct-typos-and-spelling-mistakes.patch
+Patch1: 0002-mount.cifs-document-SMBv3.1.1-and-new-seal-option.patch
+
%if 0%{?suse_version} >= 1221
%define systemd 1
%else
@@ -114,6 +118,8 @@
%prep
%setup -q
cp -a ${RPM_SOURCE_DIR}/README.cifstab.migration .
+%patch0 -p1
+%patch1 -p1
%build
export CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE -fpie"
++++++ 0001-manpage-correct-typos-and-spelling-mistakes.patch ++++++
From 9ba078eb179f713d4f1b5e8d7e416a0e86d8053e Mon Sep 17 00:00:00 2001
From: Aurelien Aptel <aap...@suse.com>
Date: Wed, 15 Feb 2017 18:10:09 +0100
Subject: [PATCH 1/2] manpage: correct typos and spelling mistakes
Signed-off-by: Aurelien Aptel <aap...@suse.com>
---
mount.cifs.8 | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/mount.cifs.8 b/mount.cifs.8
index 01579f6..9104fae 100644
--- a/mount.cifs.8
+++ b/mount.cifs.8
@@ -324,7 +324,7 @@ See section \fIACCESSING FILES WITH BACKUP INTENT\fR for
more details
.PP
nocase
.RS 4
-Request case insensitive path name matching (case sensitive is the default if
the server suports it)\&.
+Request case insensitive path name matching (case sensitive is the default if
the server supports it)\&.
.RE
.PP
ignorecase
@@ -457,7 +457,7 @@ Enable support for Minshall+French symlinks(see
http://wiki.samba.org/index.php/
.PP
serverino
.RS 4
-Use inode numbers (unique persistent file identifiers) returned by the server
instead of automatically generating temporary inode numbers on the client\&.
Although server inode numbers make it easier to spot hardlinked files (as they
will have the same inode numbers) and inode numbers may be persistent (which is
userful for some sofware), the server does not guarantee that the inode numbers
are unique if multiple server side mounts are exported under a single share
(since inode numbers on the servers might not be unique if multiple filesystems
are mounted under the same shared higher level directory)\&. Note that not all
servers support returning server inode numbers, although those that support the
CIFS Unix Extensions, and Windows 2000 and later servers typically do support
this (although not necessarily on every local server filesystem)\&. Parameter
has no effect if the server lacks support for returning inode numbers or
equivalent\&. This behavior is enabled by default\&.
+Use inode numbers (unique persistent file identifiers) returned by the server
instead of automatically generating temporary inode numbers on the client\&.
Although server inode numbers make it easier to spot hardlinked files (as they
will have the same inode numbers) and inode numbers may be persistent (which is
useful for some software), the server does not guarantee that the inode numbers
are unique if multiple server side mounts are exported under a single share
(since inode numbers on the servers might not be unique if multiple filesystems
are mounted under the same shared higher level directory)\&. Note that not all
servers support returning server inode numbers, although those that support the
CIFS Unix Extensions, and Windows 2000 and later servers typically do support
this (although not necessarily on every local server filesystem)\&. Parameter
has no effect if the server lacks support for returning inode numbers or
equivalent\&. This behavior is enabled by default\&.
.RE
.PP
noserverino
@@ -485,7 +485,7 @@ Do not allow getfattr/setfattr to get/set xattrs, even if
server would support i
.PP
rsize=\fIbytes\fR
.RS 4
-Maximum amount of data that the kernel will request in a read request in
bytes. Prior to kernel 3.2.0, the default was 16k, and the maximum size was
limited by the CIFSMaxBufSize module parameter. As of kernel 3.2.0, the
behavior varies according to whether POSIX extensions are enabled on the mount
and the server supports large POSIX reads. If they are, then the default is 1M,
and the maxmimum is 16M. If they are not supported by the server, then the
default is 60k and the maximum is around 127k. The reason for the 60k is
because it's the maximum size read that windows servers can fill. Note that
this value is a maximum, and the client may settle on a smaller size to
accomodate what the server supports. In kernels prior to 3.2.0, no negotiation
is performed.
+Maximum amount of data that the kernel will request in a read request in
bytes. Prior to kernel 3.2.0, the default was 16k, and the maximum size was
limited by the CIFSMaxBufSize module parameter. As of kernel 3.2.0, the
behavior varies according to whether POSIX extensions are enabled on the mount
and the server supports large POSIX reads. If they are, then the default is 1M,
and the maximum is 16M. If they are not supported by the server, then the
default is 60k and the maximum is around 127k. The reason for the 60k is
because it's the maximum size read that windows servers can fill. Note that
this value is a maximum, and the client may settle on a smaller size to
accommodate what the server supports. In kernels prior to 3.2.0, no negotiation
is performed.
.RE
.PP
wsize=\fIbytes\fR
@@ -506,7 +506,7 @@ multiuser
.RS 4
Map user accesses to individual credentials when accessing the server\&. By
default, CIFS mounts only use a single set of user credentials (the mount
credentials) when accessing a share\&. With this option, the client instead
creates a new session with the server using the user's credentials whenever a
new user accesses the mount. Further accesses by that user will also use those
credentials\&. Because the kernel cannot prompt for passwords, multiuser mounts
are limited to mounts using sec= options that don't require passwords.
.sp
-With this change, it's feasible for the server to handle permissions
enforcement, so this option also implies "noperm"\&. Furthermore, when unix
extensions aren't in use and the administrator has not overriden ownership
using the uid= or gid= options, ownership of files is presented as the current
user accessing the share\&.
+With this change, it's feasible for the server to handle permissions
enforcement, so this option also implies "noperm"\&. Furthermore, when unix
extensions aren't in use and the administrator has not overridden ownership
using the uid= or gid= options, ownership of files is presented as the current
user accessing the share\&.
.RE
.PP
actimeo=\fIarg\fR
@@ -605,7 +605,7 @@ mount \-t cifs //server/share /mnt \-\-verbose \-o
user=username
.RE
.SH "SERVICE FORMATTING AND DELIMITERS"
.PP
-It\'s generally preferred to use forward slashes (/) as a delimiter in service
names\&. They are considered to be the "universal delimiter" since they are
generally not allowed to be embedded within path components on Windows machines
and the client can convert them to blackslashes (\e) unconditionally\&.
Conversely, backslash characters are allowed by POSIX to be part of a path
component, and can\'t be automatically converted in the same way\&.
+It\'s generally preferred to use forward slashes (/) as a delimiter in service
names\&. They are considered to be the "universal delimiter" since they are
generally not allowed to be embedded within path components on Windows machines
and the client can convert them to backslashes (\e) unconditionally\&.
Conversely, backslash characters are allowed by POSIX to be part of a path
component, and can\'t be automatically converted in the same way\&.
.PP
mount\&.cifs will attempt to convert backslashes to forward slashes where
it\'s able to do so, but it cannot do so in any path component following the
sharename\&.
.SH "INODE NUMBERS"
@@ -753,7 +753,7 @@ If either upcall to cifs.idmap is not setup correctly or
winbind is not configur
.RE
.SH "ACCESSING FILES WITH BACKUP INTENT"
.PP
-For an user on the server, desired access to a file is determined by the
permissions and rights associated with that file. This is typically
accomplished using owenrship and ACL. For a user who does not have access
rights to a file, it is still possible to access that file for a specific or a
targeted purpose by granting special rights. One of the specific purposes is
to access a file with the intent to either backup or restore i.e. backup
intent. The right to access a file with the backup intent can typically be
granted by making that user a part of the built-in group Backup Operators.
Thus, when this user attempts to open a file with the backup intent, open
request is sent by setting the bit FILE_OPEN_FOR_BACKUP_INTENT as one of the
CreateOptions.
+For an user on the server, desired access to a file is determined by the
permissions and rights associated with that file. This is typically
accomplished using ownership and ACL. For a user who does not have access
rights to a file, it is still possible to access that file for a specific or a
targeted purpose by granting special rights. One of the specific purposes is
to access a file with the intent to either backup or restore i.e. backup
intent. The right to access a file with the backup intent can typically be
granted by making that user a part of the built-in group Backup Operators.
Thus, when this user attempts to open a file with the backup intent, open
request is sent by setting the bit FILE_OPEN_FOR_BACKUP_INTENT as one of the
CreateOptions.
As an example, on a Windows server, a user named testuser, cannot open this
file with such a security descriptor.
.PP
@@ -772,7 +772,7 @@ But the user testuser, if it becomes part of the group
Backup Operators, can ope
Any user on the client side who can authenticate as such a user on the server,
can access the files with the backup intent. But it is desirable and
preferable for security reasons amongst many, to restrict this special right.
-The mount option backupuid is used to restrict this special right to a user
which is specified by either a name or an id. The mount option backupgid is
used to restrict this special right to the users in a group which is specified
by either a name or an id. Only users maching either backupuid or backupgid
shall attempt to access files with backup intent. These two mount options can
be used together.
+The mount option backupuid is used to restrict this special right to a user
which is specified by either a name or an id. The mount option backupgid is
used to restrict this special right to the users in a group which is specified
by either a name or an id. Only users matching either backupuid or backupgid
shall attempt to access files with backup intent. These two mount options can
be used together.
.SH "FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS"
.PP
The core CIFS protocol does not provide unix ownership information or mode for
files and directories\&. Because of this, files and directories will generally
appear to be owned by whatever values the uid= or gid= options are set, and
will have permissions set to the default file_mode and dir_mode for the
mount\&. Attempting to change these values via chmod/chown will return success
but have no effect\&.
@@ -783,7 +783,7 @@ If the uid\'s and gid\'s being used do not match on the
client and server, the f
.PP
When unix extensions are not negotiated, it\'s also possible to emulate them
locally on the server using the "dynperm" mount option\&. When this mount
option is in effect, newly created files and directories will receive what
appear to be proper permissions\&. These permissions are not stored on the
server however and can disappear at any time in the future (subject to the
whims of the kernel flushing out the inode cache)\&. In general, this mount
option is discouraged\&.
.PP
-It\'s also possible to override permission checking on the client altogether
via the noperm option\&. Server\-side permission checks cannot be overriden\&.
The permission checks done by the server will always correspond to the
credentials used to mount the share, and not necessarily to the user who is
accessing the share\&.
+It\'s also possible to override permission checking on the client altogether
via the noperm option\&. Server\-side permission checks cannot be overridden\&.
The permission checks done by the server will always correspond to the
credentials used to mount the share, and not necessarily to the user who is
accessing the share\&.
.SH "ENVIRONMENT VARIABLES"
.PP
The variable
@@ -799,7 +799,7 @@ The variable
may contain the pathname of a file to read the password from\&. A single line
of input is read and used as the password\&.
.SH "NOTES"
.PP
-This command may be used only by root, unless installed setuid, in which case
the noeexec and nosuid mount flags are enabled\&. When installed as a setuid
program, the program follows the conventions set forth by the mount program for
user mounts, with the added restriction that users must be able to chdir() into
the
+This command may be used only by root, unless installed setuid, in which case
the noexec and nosuid mount flags are enabled\&. When installed as a setuid
program, the program follows the conventions set forth by the mount program for
user mounts, with the added restriction that users must be able to chdir() into
the
mountpoint prior to the mount in order to be able to mount onto it.
.PP
Some samba client tools like smbclient(8) honour client\-side configuration
parameters present in smb\&.conf\&. Unlike those client tools,
--
2.12.0
++++++ 0002-mount.cifs-document-SMBv3.1.1-and-new-seal-option.patch ++++++
From 5513fa5aa37602b8716b7d28b1ca5cf99d446efd Mon Sep 17 00:00:00 2001
From: Aurelien Aptel <aap...@suse.com>
Date: Fri, 21 Apr 2017 16:59:50 +0200
Subject: [PATCH 2/2] mount.cifs: document SMBv3.1.1 and new seal option
Signed-off-by: Aurelien Aptel <aap...@suse.com>
---
mount.cifs.8 | 16 ++++++++++++++++
mount.cifs.c | 2 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/mount.cifs.8 b/mount.cifs.8
index 9104fae..ab35448 100644
--- a/mount.cifs.8
+++ b/mount.cifs.8
@@ -440,6 +440,11 @@ The default in mainline kernel versions prior to v3.8 was
sec=ntlm. In v3.8, the
If the server requires signing during protocol negotiation, then it may be
enabled automatically. Packet signing may also be enabled automatically if it's
enabled in /proc/fs/cifs/SecurityFlags.
.RE
.PP
+seal
+.RS 4
+Request encryption at the SMB layer. Encryption is only supported in SMBv3 and
above. The encryption algorithm used is AES-128-CCM.
+.RE
+.PP
nobrl
.RS 4
Do not send byte range lock requests to the server\&. This is necessary for
certain applications that break with cifs style mandatory byte range locks (and
most cifs servers do not yet support requesting advisory byte range locks)\&.
@@ -593,6 +598,17 @@ SMB protocol version. Allowed values are:
.\}
3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and
Windows Server 2012.
.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft
Windows Server 2016.
+.RE
.PP
Note too that while this option governs the protocol version used, not all
features of each version are available.
.RE
diff --git a/mount.cifs.c b/mount.cifs.c
index 2612feb..8ca848d 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
@@ -269,7 +269,7 @@ static int mount_usage(FILE * stream)
fprintf(stream,
"\n\tmapchars,nomapchars,nolock,servernetbiosname=<SRV_RFC1001NAME>");
fprintf(stream,
- "\n\tdirectio,nounix,cifsacl,sec=<authentication
mechanism>,sign,fsc");
+ "\n\tdirectio,nounix,cifsacl,sec=<authentication
mechanism>,sign,seal,fsc");
fprintf(stream,
"\n\nOptions not needed for servers supporting CIFS Unix
extensions");
fprintf(stream,
--
2.12.0
