1. 25 6月, 2009 1 次提交
  2. 13 6月, 2009 1 次提交
  3. 11 6月, 2009 1 次提交
  4. 10 6月, 2009 1 次提交
  5. 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
  6. 02 6月, 2009 1 次提交
  7. 28 5月, 2009 1 次提交
  8. 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
  9. 06 5月, 2009 1 次提交
  10. 02 5月, 2009 1 次提交
  11. 01 5月, 2009 6 次提交
  12. 30 4月, 2009 1 次提交
  13. 17 4月, 2009 7 次提交
  14. 18 3月, 2009 1 次提交
  15. 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
  16. 21 2月, 2009 1 次提交
  17. 31 1月, 2009 1 次提交
  18. 29 1月, 2009 3 次提交
  19. 26 12月, 2008 8 次提交