Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 28 7月, 2009 1 次提交
  3. 23 7月, 2009 1 次提交
    • J
      cifs: fix sb->s_maxbytes so that it casts properly to a signed value · 03aa3a49
      由 Jeff Layton 提交于 
      This off-by-one bug causes sendfile() to not work properly. When a task
calls sendfile() on a file on a CIFS filesystem, the syscall returns -1
and sets errno to EOVERFLOW.

do_sendfile uses s_maxbytes to verify the returned offset of the file.
The problem there is that this value is cast to a signed value (loff_t).
When this is done on the s_maxbytes value that cifs uses, it becomes
negative and the comparisons against it fail.

Even though s_maxbytes is an unsigned value, it seems that it's not OK
to set it in such a way that it'll end up negative when it's cast to a
signed value. These casts happen in other codepaths besides sendfile
too, but the VFS is a little hard to follow in this area and I can't
be sure if there are other bugs that this will fix.

It's not clear to me why s_maxbytes isn't just declared as loff_t in the
first place, but either way we still need to fix these values to make
sendfile work properly. This is also an opportunity to replace the magic
bit-shift values here with the standard #defines for this.

This fixes the reproducer program I have that does a sendfile and
will probably also fix the situation where apache is serving from a
CIFS share.
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      03aa3a49
  5. 21 7月, 2009 1 次提交
  7. 26 6月, 2009 1 次提交
  9. 25 6月, 2009 3 次提交
  11. 13 6月, 2009 1 次提交
  13. 11 6月, 2009 1 次提交
  15. 10 6月, 2009 1 次提交
  17. 07 6月, 2009 1 次提交
    • J
      cifs: make overriding of ownership conditional on new mount options · 4ae1507f
      由 Jeff Layton 提交于 
      We have a bit of a problem with the uid= option. The basic issue is that
it means too many things and has too many side-effects.

It's possible to allow an unprivileged user to mount a filesystem if the
user owns the mountpoint, /bin/mount is setuid root, and the mount is
set up in /etc/fstab with the "user" option.

When doing this though, /bin/mount automatically adds the "uid=" and
"gid=" options to the share. This is fortunate since the correct uid=
option is needed in order to tell the upcall what user's credcache to
use when generating the SPNEGO blob.

On a mount without unix extensions this is fine -- you generally will
want the files to be owned by the "owner" of the mount. The problem
comes in on a mount with unix extensions. With those enabled, the
uid/gid options cause the ownership of files to be overriden even though
the server is sending along the ownership info.

This means that it's not possible to have a mount by an unprivileged
user that shows the server's file ownership info. The result is also
inode permissions that have no reflection at all on the server. You
simply cannot separate ownership from the mode in this fashion.

This behavior also makes MultiuserMount option less usable. Once you
pass in the uid= option for a mount, then you can't use unix ownership
info and allow someone to share the mount.

While I'm not thrilled with it, the only solution I can see is to stop
making uid=/gid= force the overriding of ownership on mounts, and to add
new mount options that turn this behavior on.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      4ae1507f
  19. 02 6月, 2009 1 次提交
  21. 28 5月, 2009 1 次提交
  23. 27 5月, 2009 1 次提交
    • J
      cifs: tighten up default file_mode/dir_mode · f55ed1a8
      由 Jeff Layton 提交于 
      The current default file mode is 02767 and dir mode is 0777. This is
extremely "loose". Given that CIFS is a single-user protocol, these
permissions allow anyone to use the mount -- in effect, giving anyone on
the machine access to the credentials used to mount the share.

Change this by making the default permissions restrict write access to
the default owner of the mount. Give read and execute permissions to
everyone else. These are the same permissions that VFAT mounts get by
default so there is some precedent here.

Note that this patch also removes the mandatory locking flags from the
default file_mode. After having looked at how these flags are used by
the kernel, I don't think that keeping them as the default offers any
real benefit. That flag combination makes it so that the kernel enforces
mandatory locking.

Since the server is going to do that for us anyway, I don't think we
want the client to enforce this by default on applications that just
want advisory locks. Anyone that does want this behavior can always
enable it by setting the file_mode appropriately.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f55ed1a8
  25. 06 5月, 2009 1 次提交
  27. 02 5月, 2009 1 次提交
  29. 01 5月, 2009 6 次提交
  31. 30 4月, 2009 1 次提交
  33. 17 4月, 2009 7 次提交
  35. 18 3月, 2009 1 次提交
  37. 12 3月, 2009 2 次提交
    • S
      [CIFS] fix build error · 4717bed6
      由 Steve French 提交于 
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      4717bed6
    • S
      [CIFS] Add new nostrictsync cifs mount option to avoid slow SMB flush · be652445
      由 Steve French 提交于 
      If this mount option is set, when an application does an
fsync call then the cifs client does not send an SMB Flush
to the server (to force the server to write all dirty data
for this file immediately to disk), although cifs still sends
all dirty (cached) file data to the server and waits for the
server to respond to the write write.  Since SMB Flush can be
very slow, and some servers may be reliable enough (to risk
delaying slightly flushing the data to disk on the server),
turning on this option may be useful to improve performance for
applications that fsync too much, at a small risk of server
crash.  If this mount option is not set, by default cifs will
send an SMB flush request (and wait for a response) on every
fsync call.
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      be652445
  39. 21 2月, 2009 1 次提交
  41. 31 1月, 2009 1 次提交
  43. 29 1月, 2009 3 次提交
  45. 26 12月, 2008 2 次提交