summaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorJeff Layton <jlayton@samba.org>2010-07-23 15:28:32 -0400
committerJeff Layton <jlayton@samba.org>2010-07-23 15:28:32 -0400
commita8eb879c080c0273d9272dac5ff41bd8a4b3440e (patch)
tree3361e4c031044dc52bec51806d8be7bd7b4fbb48 /NEWS
parent98b3723c75d295e8718f1440f91a2c678608f658 (diff)
downloadcifs-utils-a8eb879c080c0273d9272dac5ff41bd8a4b3440e.tar.gz
cifs-utils-a8eb879c080c0273d9272dac5ff41bd8a4b3440e.tar.bz2
cifs-utils-a8eb879c080c0273d9272dac5ff41bd8a4b3440e.zip
cifs.upcall: use "creduid=" parm by default when available
When I did the original krb5 implementation, I goofed and ended up making it so that when someone specifies the "uid=" mount option that also affects the owner of the krb5 credential cache and not just the ownership of the mount. I'm proposing a patch for the kernel to attempt to fix this by making the kernel send a "creduid=" parameter in the upcall which is intended to be the user that should own the credentials cache. That's not necessarily the same user that has "ownership" of the mount. Usually the creduid= will be set to the real uid of the user doing the mounting. When multisession mounts are introduced they will usually set this to the fsuid that walks into the mount. To ease the transition, this patch also adds a command line switch that makes cifs.upcall use the "legacy" uid= parameter instead. Use that if you want it to behave like it used to. Signed-off-by: Jeff Layton <jlayton@samba.org>
Diffstat (limited to 'NEWS')
0 files changed, 0 insertions, 0 deletions