Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 6月, 2009 1 次提交
  3. 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
  7. 02 6月, 2009 1 次提交
  9. 28 5月, 2009 1 次提交
  11. 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
  13. 06 5月, 2009 1 次提交
  15. 02 5月, 2009 1 次提交
  17. 01 5月, 2009 6 次提交
  19. 30 4月, 2009 1 次提交
  21. 17 4月, 2009 7 次提交
  23. 18 3月, 2009 1 次提交
  25. 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
  27. 21 2月, 2009 1 次提交
  29. 31 1月, 2009 1 次提交
  31. 29 1月, 2009 3 次提交
  33. 26 12月, 2008 10 次提交