original development tree for Linux kernel GTP module; now long in mainline.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1566 lines
51 KiB

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
12 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
Make CIFS mount work in a container. Teach cifs about network namespaces, so mounting uses adresses/routing visible from the container rather than from init context. A container is a chroot on steroids that changes more than just the root filesystem the new processes see. One thing containers can isolate is "network namespaces", meaning each container can have its own set of ethernet interfaces, each with its own own IP address and routing to the outside world. And if you open a socket in _userspace_ from processes within such a container, this works fine. But sockets opened from within the kernel still use a single global networking context in a lot of places, meaning the new socket's address and routing are correct for PID 1 on the host, but are _not_ what userspace processes in the container get to use. So when you mount a network filesystem from within in a container, the mount code in the CIFS driver uses the host's networking context and not the container's networking context, so it gets the wrong address, uses the wrong routing, and may even try to go out an interface that the container can't even access... Bad stuff. This patch copies the mount process's network context into the CIFS structure that stores the rest of the server information for that mount point, and changes the socket open code to use the saved network context instead of the global network context. I.E. "when you attempt to use these addresses, do so relative to THIS set of network interfaces and routing rules, not the old global context from back before we supported containers". The big long HOWTO sets up a test environment on the assumption you've never used ocntainers before. It basically says: 1) configure and build a new kernel that has container support 2) build a new root filesystem that includes the userspace container control package (LXC) 3) package/run them under KVM (so you don't have to mess up your host system in order to play with containers). 4) set up some containers under the KVM system 5) set up contradictory routing in the KVM system and the container so that the host and the container see different things for the same address 6) try to mount a CIFS share from both contexts so you can both force it to work and force it to fail. For a long drawn out test reproduction sequence, see: http://landley.livejournal.com/47024.html http://landley.livejournal.com/47205.html http://landley.livejournal.com/47476.html Signed-off-by: Rob Landley <rlandley@parallels.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange Mark dependency on crypto modules in Kconfig. Defining per structures sdesc and cifs_secmech which are used to store crypto hash functions and contexts. They are stored per smb connection and used for all auth mechs to genereate hash values and signatures. Allocate crypto hashing functions, security descriptiors, and respective contexts when a smb/tcp connection is established. Release them when a tcp/smb connection is taken down. md5 and hmac-md5 are two crypto hashing functions that are used throught the life of an smb/tcp connection by various functions that calcualte signagure and ntlmv2 hash, HMAC etc. structure ntlmssp_auth is defined as per smb connection. ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of secondary key, a nonce using ntlmv2 session key and sent in the session key field of the type 3 message sent by the client during ntlmssp negotiation/exchange A key is exchanged with the server if client indicates so in flags in type 1 messsage and server agrees in flag in type 2 message of ntlmssp negotiation. If both client and agree, a key sent by client in type 3 message of ntlmssp negotiation in the session key field. The key is a ciphertext generated off of secondary key, a nonce, using ntlmv2 hash via rc4/arc4. Signing works for ntlmssp in this patch. The sequence number within the server structure needs to be zero until session is established i.e. till type 3 packet of ntlmssp exchange of a to be very first smb session on that smb connection is sent. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
Make CIFS mount work in a container. Teach cifs about network namespaces, so mounting uses adresses/routing visible from the container rather than from init context. A container is a chroot on steroids that changes more than just the root filesystem the new processes see. One thing containers can isolate is "network namespaces", meaning each container can have its own set of ethernet interfaces, each with its own own IP address and routing to the outside world. And if you open a socket in _userspace_ from processes within such a container, this works fine. But sockets opened from within the kernel still use a single global networking context in a lot of places, meaning the new socket's address and routing are correct for PID 1 on the host, but are _not_ what userspace processes in the container get to use. So when you mount a network filesystem from within in a container, the mount code in the CIFS driver uses the host's networking context and not the container's networking context, so it gets the wrong address, uses the wrong routing, and may even try to go out an interface that the container can't even access... Bad stuff. This patch copies the mount process's network context into the CIFS structure that stores the rest of the server information for that mount point, and changes the socket open code to use the saved network context instead of the global network context. I.E. "when you attempt to use these addresses, do so relative to THIS set of network interfaces and routing rules, not the old global context from back before we supported containers". The big long HOWTO sets up a test environment on the assumption you've never used ocntainers before. It basically says: 1) configure and build a new kernel that has container support 2) build a new root filesystem that includes the userspace container control package (LXC) 3) package/run them under KVM (so you don't have to mess up your host system in order to play with containers). 4) set up some containers under the KVM system 5) set up contradictory routing in the KVM system and the container so that the host and the container see different things for the same address 6) try to mount a CIFS share from both contexts so you can both force it to work and force it to fail. For a long drawn out test reproduction sequence, see: http://landley.livejournal.com/47024.html http://landley.livejournal.com/47205.html http://landley.livejournal.com/47476.html Signed-off-by: Rob Landley <rlandley@parallels.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
11 years ago
cifs: Add data structures and functions for uid/gid to SID mapping (try #4) Add data structures and functions necessary to map a uid and gid to SID. These functions are very similar to the ones used to map a SID to uid and gid. This time, instead of storing sid to id mapping sorted on a sid value, id to sid is stored, sorted on an id. A cifs upcall sends an id (uid or gid) and expects a SID structure in return, if mapping was done successfully. A failed id to sid mapping to EINVAL. This patchset aims to enable chown and chgrp commands when cifsacl mount option is specified, especially to Windows SMB servers. Currently we can't do that. So now along with chmod command, chown and chgrp work. Winbind is used to map id to a SID. chown and chgrp use an upcall to provide an id to winbind and upcall returns with corrosponding SID if any exists. That SID is used to build security descriptor. The DACL part of a security descriptor is not changed by either chown or chgrp functionality. cifs client maintains a separate caches for uid to SID and gid to SID mapping. This is similar to the one used earlier to map SID to id (as part of ID mapping code). I tested it by mounting shares from a Windows (2003) server by authenticating as two users, one at a time, as Administrator and as a ordinary user. And then attempting to change owner of a file on the share. Depending on the permissions/privileges at the server for that file, chown request fails to either open a file (to change the ownership) or to set security descriptor. So it all depends on privileges on the file at the server and what user you are authenticated as at the server, cifs client is just a conduit. I compared the security descriptor during chown command to that what smbcacls sends when it is used with -M OWNNER: option and they are similar. This patchset aim to enable chown and chgrp commands when cifsacl mount option is specified, especially to Windows SMB servers. Currently we can't do that. So now along with chmod command, chown and chgrp work. I tested it by mounting shares from a Windows (2003) server by authenticating as two users, one at a time, as Administrator and as a ordinary user. And then attempting to change owner of a file on the share. Depending on the permissions/privileges at the server for that file, chown request fails to either open a file (to change the ownership) or to set security descriptor. So it all depends on privileges on the file at the server and what user you are authenticated as at the server, cifs client is just a conduit. Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <smfrench@gmail.com>
10 years ago
cifs: Add data structures and functions for uid/gid to SID mapping (try #4) Add data structures and functions necessary to map a uid and gid to SID. These functions are very similar to the ones used to map a SID to uid and gid. This time, instead of storing sid to id mapping sorted on a sid value, id to sid is stored, sorted on an id. A cifs upcall sends an id (uid or gid) and expects a SID structure in return, if mapping was done successfully. A failed id to sid mapping to EINVAL. This patchset aims to enable chown and chgrp commands when cifsacl mount option is specified, especially to Windows SMB servers. Currently we can't do that. So now along with chmod command, chown and chgrp work. Winbind is used to map id to a SID. chown and chgrp use an upcall to provide an id to winbind and upcall returns with corrosponding SID if any exists. That SID is used to build security descriptor. The DACL part of a security descriptor is not changed by either chown or chgrp functionality. cifs client maintains a separate caches for uid to SID and gid to SID mapping. This is similar to the one used earlier to map SID to id (as part of ID mapping code). I tested it by mounting shares from a Windows (2003) server by authenticating as two users, one at a time, as Administrator and as a ordinary user. And then attempting to change owner of a file on the share. Depending on the permissions/privileges at the server for that file, chown request fails to either open a file (to change the ownership) or to set security descriptor. So it all depends on privileges on the file at the server and what user you are authenticated as at the server, cifs client is just a conduit. I compared the security descriptor during chown command to that what smbcacls sends when it is used with -M OWNNER: option and they are similar. This patchset aim to enable chown and chgrp commands when cifsacl mount option is specified, especially to Windows SMB servers. Currently we can't do that. So now along with chmod command, chown and chgrp work. I tested it by mounting shares from a Windows (2003) server by authenticating as two users, one at a time, as Administrator and as a ordinary user. And then attempting to change owner of a file on the share. Depending on the permissions/privileges at the server for that file, chown request fails to either open a file (to change the ownership) or to set security descriptor. So it all depends on privileges on the file at the server and what user you are authenticated as at the server, cifs client is just a conduit. Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Steve French <smfrench@gmail.com>
10 years ago
  1. /*
  2. * fs/cifs/cifsglob.h
  3. *
  4. * Copyright (C) International Business Machines Corp., 2002,2008
  5. * Author(s): Steve French (sfrench@us.ibm.com)
  6. * Jeremy Allison (jra@samba.org)
  7. *
  8. * This library is free software; you can redistribute it and/or modify
  9. * it under the terms of the GNU Lesser General Public License as published
  10. * by the Free Software Foundation; either version 2.1 of the License, or
  11. * (at your option) any later version.
  12. *
  13. * This library is distributed in the hope that it will be useful,
  14. * but WITHOUT ANY WARRANTY; without even the implied warranty of
  15. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
  16. * the GNU Lesser General Public License for more details.
  17. *
  18. */
  19. #ifndef _CIFS_GLOB_H
  20. #define _CIFS_GLOB_H
  21. #include <linux/in.h>
  22. #include <linux/in6.h>
  23. #include <linux/slab.h>
  24. #include <linux/mempool.h>
  25. #include <linux/workqueue.h>
  26. #include "cifs_fs_sb.h"
  27. #include "cifsacl.h"
  28. #include <crypto/internal/hash.h>
  29. #include <linux/scatterlist.h>
  30. #include <uapi/linux/cifs/cifs_mount.h>
  31. #ifdef CONFIG_CIFS_SMB2
  32. #include "smb2pdu.h"
  33. #endif
  34. #define CIFS_MAGIC_NUMBER 0xFF534D42 /* the first four bytes of SMB PDUs */
  35. /*
  36. * The sizes of various internal tables and strings
  37. */
  38. #define MAX_UID_INFO 16
  39. #define MAX_SES_INFO 2
  40. #define MAX_TCON_INFO 4
  41. #define MAX_TREE_SIZE (2 + CIFS_NI_MAXHOST + 1 + CIFS_MAX_SHARE_LEN + 1)
  42. #define CIFS_MIN_RCV_POOL 4
  43. #define MAX_REOPEN_ATT 5 /* these many maximum attempts to reopen a file */
  44. /*
  45. * default attribute cache timeout (jiffies)
  46. */
  47. #define CIFS_DEF_ACTIMEO (1 * HZ)
  48. /*
  49. * max attribute cache timeout (jiffies) - 2^30
  50. */
  51. #define CIFS_MAX_ACTIMEO (1 << 30)
  52. /*
  53. * MAX_REQ is the maximum number of requests that WE will send
  54. * on one socket concurrently.
  55. */
  56. #define CIFS_MAX_REQ 32767
  57. #define RFC1001_NAME_LEN 15
  58. #define RFC1001_NAME_LEN_WITH_NULL (RFC1001_NAME_LEN + 1)
  59. /* currently length of NIP6_FMT */
  60. #define SERVER_NAME_LENGTH 40
  61. #define SERVER_NAME_LEN_WITH_NULL (SERVER_NAME_LENGTH + 1)
  62. /* used to define string lengths for reversing unicode strings */
  63. /* (256+1)*2 = 514 */
  64. /* (max path length + 1 for null) * 2 for unicode */
  65. #define MAX_NAME 514
  66. /* SMB echo "timeout" -- FIXME: tunable? */
  67. #define SMB_ECHO_INTERVAL (60 * HZ)
  68. #include "cifspdu.h"
  69. #ifndef XATTR_DOS_ATTRIB
  70. #define XATTR_DOS_ATTRIB "user.DOSATTRIB"
  71. #endif
  72. /*
  73. * CIFS vfs client Status information (based on what we know.)
  74. */
  75. /* associated with each tcp and smb session */
  76. enum statusEnum {
  77. CifsNew = 0,
  78. CifsGood,
  79. CifsExiting,
  80. CifsNeedReconnect,
  81. CifsNeedNegotiate
  82. };
  83. enum securityEnum {
  84. Unspecified = 0, /* not specified */
  85. LANMAN, /* Legacy LANMAN auth */
  86. NTLM, /* Legacy NTLM012 auth with NTLM hash */
  87. NTLMv2, /* Legacy NTLM auth with NTLMv2 hash */
  88. RawNTLMSSP, /* NTLMSSP without SPNEGO, NTLMv2 hash */
  89. Kerberos, /* Kerberos via SPNEGO */
  90. };
  91. struct session_key {
  92. unsigned int len;
  93. char *response;
  94. };
  95. /* crypto security descriptor definition */
  96. struct sdesc {
  97. struct shash_desc shash;
  98. char ctx[];
  99. };
  100. /* crypto hashing related structure/fields, not specific to a sec mech */
  101. struct cifs_secmech {
  102. struct crypto_shash *hmacmd5; /* hmac-md5 hash function */
  103. struct crypto_shash *md5; /* md5 hash function */
  104. struct crypto_shash *hmacsha256; /* hmac-sha256 hash function */
  105. struct crypto_shash *cmacaes; /* block-cipher based MAC function */
  106. struct sdesc *sdeschmacmd5; /* ctxt to generate ntlmv2 hash, CR1 */
  107. struct sdesc *sdescmd5; /* ctxt to generate cifs/smb signature */
  108. struct sdesc *sdeschmacsha256; /* ctxt to generate smb2 signature */
  109. struct sdesc *sdesccmacaes; /* ctxt to generate smb3 signature */
  110. };
  111. /* per smb session structure/fields */
  112. struct ntlmssp_auth {
  113. bool sesskey_per_smbsess; /* whether session key is per smb session */
  114. __u32 client_flags; /* sent by client in type 1 ntlmsssp exchange */
  115. __u32 server_flags; /* sent by server in type 2 ntlmssp exchange */
  116. unsigned char ciphertext[CIFS_CPHTXT_SIZE]; /* sent to server */
  117. char cryptkey[CIFS_CRYPTO_KEY_SIZE]; /* used by ntlmssp */
  118. };
  119. struct cifs_cred {
  120. int uid;
  121. int gid;
  122. int mode;
  123. int cecount;
  124. struct cifs_sid osid;
  125. struct cifs_sid gsid;
  126. struct cifs_ntace *ntaces;
  127. struct cifs_ace *aces;
  128. };
  129. /*
  130. *****************************************************************
  131. * Except the CIFS PDUs themselves all the
  132. * globally interesting structs should go here
  133. *****************************************************************
  134. */
  135. /*
  136. * A smb_rqst represents a complete request to be issued to a server. It's
  137. * formed by a kvec array, followed by an array of pages. Page data is assumed
  138. * to start at the beginning of the first page.
  139. */
  140. struct smb_rqst {
  141. struct kvec *rq_iov; /* array of kvecs */
  142. unsigned int rq_nvec; /* number of kvecs in array */
  143. struct page **rq_pages; /* pointer to array of page ptrs */
  144. unsigned int rq_npages; /* number pages in array */
  145. unsigned int rq_pagesz; /* page size to use */
  146. unsigned int rq_tailsz; /* length of last page */
  147. };
  148. enum smb_version {
  149. Smb_1 = 1,
  150. Smb_20,
  151. Smb_21,
  152. Smb_30,
  153. Smb_302,
  154. };
  155. struct mid_q_entry;
  156. struct TCP_Server_Info;
  157. struct cifsFileInfo;
  158. struct cifs_ses;
  159. struct cifs_tcon;
  160. struct dfs_info3_param;
  161. struct cifs_fattr;
  162. struct smb_vol;
  163. struct cifs_fid;
  164. struct cifs_readdata;
  165. struct cifs_writedata;
  166. struct cifs_io_parms;
  167. struct cifs_search_info;
  168. struct cifsInodeInfo;
  169. struct cifs_open_parms;
  170. struct smb_version_operations {
  171. int (*send_cancel)(struct TCP_Server_Info *, void *,
  172. struct mid_q_entry *);
  173. bool (*compare_fids)(struct cifsFileInfo *, struct cifsFileInfo *);
  174. /* setup request: allocate mid, sign message */
  175. struct mid_q_entry *(*setup_request)(struct cifs_ses *,
  176. struct smb_rqst *);
  177. /* setup async request: allocate mid, sign message */
  178. struct mid_q_entry *(*setup_async_request)(struct TCP_Server_Info *,
  179. struct smb_rqst *);
  180. /* check response: verify signature, map error */
  181. int (*check_receive)(struct mid_q_entry *, struct TCP_Server_Info *,
  182. bool);
  183. void (*add_credits)(struct TCP_Server_Info *, const unsigned int,
  184. const int);
  185. void (*set_credits)(struct TCP_Server_Info *, const int);
  186. int * (*get_credits_field)(struct TCP_Server_Info *, const int);
  187. unsigned int (*get_credits)(struct mid_q_entry *);
  188. __u64 (*get_next_mid)(struct TCP_Server_Info *);
  189. /* data offset from read response message */
  190. unsigned int (*read_data_offset)(char *);
  191. /* data length from read response message */
  192. unsigned int (*read_data_length)(char *);
  193. /* map smb to linux error */
  194. int (*map_error)(char *, bool);
  195. /* find mid corresponding to the response message */
  196. struct mid_q_entry * (*find_mid)(struct TCP_Server_Info *, char *);
  197. void (*dump_detail)(void *);
  198. void (*clear_stats)(struct cifs_tcon *);
  199. void (*print_stats)(struct seq_file *m, struct cifs_tcon *);
  200. void (*dump_share_caps)(struct seq_file *, struct cifs_tcon *);
  201. /* verify the message */
  202. int (*check_message)(char *, unsigned int);
  203. bool (*is_oplock_break)(char *, struct TCP_Server_Info *);
  204. /* process transaction2 response */
  205. bool (*check_trans2)(struct mid_q_entry *, struct TCP_Server_Info *,
  206. char *, int);
  207. /* check if we need to negotiate */
  208. bool (*need_neg)(struct TCP_Server_Info *);
  209. /* negotiate to the server */
  210. int (*negotiate)(const unsigned int, struct cifs_ses *);
  211. /* set negotiated write size */
  212. unsigned int (*negotiate_wsize)(struct cifs_tcon *, struct smb_vol *);
  213. /* set negotiated read size */
  214. unsigned int (*negotiate_rsize)(struct cifs_tcon *, struct smb_vol *);
  215. /* setup smb sessionn */
  216. int (*sess_setup)(const unsigned int, struct cifs_ses *,
  217. const struct nls_table *);
  218. /* close smb session */
  219. int (*logoff)(const unsigned int, struct cifs_ses *);
  220. /* connect to a server share */
  221. int (*tree_connect)(const unsigned int, struct cifs_ses *, const char *,
  222. struct cifs_tcon *, const struct nls_table *);
  223. /* close tree connecion */
  224. int (*tree_disconnect)(const unsigned int, struct cifs_tcon *);
  225. /* get DFS referrals */
  226. int (*get_dfs_refer)(const unsigned int, struct cifs_ses *,
  227. const char *, struct dfs_info3_param **,
  228. unsigned int *, const struct nls_table *, int);
  229. /* informational QFS call */
  230. void (*qfs_tcon)(const unsigned int, struct cifs_tcon *);
  231. /* check if a path is accessible or not */
  232. int (*is_path_accessible)(const unsigned int, struct cifs_tcon *,
  233. struct cifs_sb_info *, const char *);
  234. /* query path data from the server */
  235. int (*query_path_info)(const unsigned int, struct cifs_tcon *,
  236. struct cifs_sb_info *, const char *,
  237. FILE_ALL_INFO *, bool *, bool *);
  238. /* query file data from the server */
  239. int (*query_file_info)(const unsigned int, struct cifs_tcon *,
  240. struct cifs_fid *, FILE_ALL_INFO *);
  241. /* get server index number */
  242. int (*get_srv_inum)(const unsigned int, struct cifs_tcon *,
  243. struct cifs_sb_info *, const char *,
  244. u64 *uniqueid, FILE_ALL_INFO *);
  245. /* set size by path */
  246. int (*set_path_size)(const unsigned int, struct cifs_tcon *,
  247. const char *, __u64, struct cifs_sb_info *, bool);
  248. /* set size by file handle */
  249. int (*set_file_size)(const unsigned int, struct cifs_tcon *,
  250. struct cifsFileInfo *, __u64, bool);
  251. /* set attributes */
  252. int (*set_file_info)(struct inode *, const char *, FILE_BASIC_INFO *,
  253. const unsigned int);
  254. int (*set_compression)(const unsigned int, struct cifs_tcon *,
  255. struct cifsFileInfo *);
  256. /* check if we can send an echo or nor */
  257. bool (*can_echo)(struct TCP_Server_Info *);
  258. /* send echo request */
  259. int (*echo)(struct TCP_Server_Info *);
  260. /* create directory */
  261. int (*mkdir)(const unsigned int, struct cifs_tcon *, const char *,
  262. struct cifs_sb_info *);
  263. /* set info on created directory */
  264. void (*mkdir_setinfo)(struct inode *, const char *,
  265. struct cifs_sb_info *, struct cifs_tcon *,
  266. const unsigned int);
  267. /* remove directory */
  268. int (*rmdir)(const unsigned int, struct cifs_tcon *, const char *,
  269. struct cifs_sb_info *);
  270. /* unlink file */
  271. int (*unlink)(const unsigned int, struct cifs_tcon *, const char *,
  272. struct cifs_sb_info *);
  273. /* open, rename and delete file */
  274. int (*rename_pending_delete)(const char *, struct dentry *,
  275. const unsigned int);
  276. /* send rename request */
  277. int (*rename)(const unsigned int, struct cifs_tcon *, const char *,
  278. const char *, struct cifs_sb_info *);
  279. /* send create hardlink request */
  280. int (*create_hardlink)(const unsigned int, struct cifs_tcon *,
  281. const char *, const char *,
  282. struct cifs_sb_info *);
  283. /* query symlink target */
  284. int (*query_symlink)(const unsigned int, struct cifs_tcon *,
  285. const char *, char **, struct cifs_sb_info *);
  286. /* open a file for non-posix mounts */
  287. int (*open)(const unsigned int, struct cifs_open_parms *,
  288. __u32 *, FILE_ALL_INFO *);
  289. /* set fid protocol-specific info */
  290. void (*set_fid)(struct cifsFileInfo *, struct cifs_fid *, __u32);
  291. /* close a file */
  292. void (*close)(const unsigned int, struct cifs_tcon *,
  293. struct cifs_fid *);
  294. /* send a flush request to the server */
  295. int (*flush)(const unsigned int, struct cifs_tcon *, struct cifs_fid *);
  296. /* async read from the server */
  297. int (*async_readv)(struct cifs_readdata *);
  298. /* async write to the server */
  299. int (*async_writev)(struct cifs_writedata *);
  300. /* sync read from the server */
  301. int (*sync_read)(const unsigned int, struct cifsFileInfo *,
  302. struct cifs_io_parms *, unsigned int *, char **,
  303. int *);
  304. /* sync write to the server */
  305. int (*sync_write)(const unsigned int, struct cifsFileInfo *,
  306. struct cifs_io_parms *, unsigned int *, struct kvec *,
  307. unsigned long);
  308. /* open dir, start readdir */
  309. int (*query_dir_first)(const unsigned int, struct cifs_tcon *,
  310. const char *, struct cifs_sb_info *,
  311. struct cifs_fid *, __u16,
  312. struct cifs_search_info *);
  313. /* continue readdir */
  314. int (*query_dir_next)(const unsigned int, struct cifs_tcon *,
  315. struct cifs_fid *,
  316. __u16, struct cifs_search_info *srch_inf);
  317. /* close dir */
  318. int (*close_dir)(const unsigned int, struct cifs_tcon *,
  319. struct cifs_fid *);
  320. /* calculate a size of SMB message */
  321. unsigned int (*calc_smb_size)(void *);
  322. /* check for STATUS_PENDING and process it in a positive case */
  323. bool (*is_status_pending)(char *, struct TCP_Server_Info *, int);
  324. /* send oplock break response */
  325. int (*oplock_response)(struct cifs_tcon *, struct cifs_fid *,
  326. struct cifsInodeInfo *);
  327. /* query remote filesystem */
  328. int (*queryfs)(const unsigned int, struct cifs_tcon *,
  329. struct kstatfs *);
  330. /* send mandatory brlock to the server */
  331. int (*mand_lock)(const unsigned int, struct cifsFileInfo *, __u64,
  332. __u64, __u32, int, int, bool);
  333. /* unlock range of mandatory locks */
  334. int (*mand_unlock_range)(struct cifsFileInfo *, struct file_lock *,
  335. const unsigned int);
  336. /* push brlocks from the cache to the server */
  337. int (*push_mand_locks)(struct cifsFileInfo *);
  338. /* get lease key of the inode */
  339. void (*get_lease_key)(struct inode *, struct cifs_fid *);
  340. /* set lease key of the inode */
  341. void (*set_lease_key)(struct inode *, struct cifs_fid *);
  342. /* generate new lease key */
  343. void (*new_lease_key)(struct cifs_fid *);
  344. int (*generate_signingkey)(struct cifs_ses *);
  345. int (*calc_signature)(struct smb_rqst *, struct TCP_Server_Info *);
  346. int (*</