- 18 7月, 2007 1 次提交
-
-
由 Usha Ketineni 提交于
Adds oid values to the gss_api mechanism structures. On the NFSV4 server side, these are required as part of the security triple (oid,qop,service) information being sent in the response of the SECINFO operation. Signed-off-by: NUsha Ketineni <uketinen@us.ibm.com> Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: NNeil Brown <neilb@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 7月, 2007 1 次提交
-
-
由 Trond Myklebust 提交于
Also do the same for gss_api operation tables. Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 04 2月, 2007 1 次提交
-
-
由 Chuck Lever 提交于
The tk_pid field is an unsigned short. The proper print format specifier for that type is %5u, not %4d. Also clean up some miscellaneous print formatting nits. Signed-off-by: NChuck Lever <chuck.lever@oracle.com> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 06 12月, 2006 3 次提交
-
-
由 J. Bruce Fields 提交于
We're currently not actually using seed or seed_init. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 J. Bruce Fields 提交于
The sealalg is checked in several places, giving the impression it could be either SEAL_ALG_NONE or SEAL_ALG_DES. But in fact SEAL_ALG_NONE seems to be sufficient only for making mic's, and all the contexts we get must be capable of wrapping as well. So the sealalg must be SEAL_ALG_DES. As with signalg, just check for the right value on the downcall and ignore it otherwise. Similarly, tighten expectations for the sealalg on incoming tokens, in case we do support other values eventually. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 J. Bruce Fields 提交于
We designed the krb5 context import without completely understanding the context. Now it's clear that there are a number of fields that we ignore, or that we depend on having one single value. In particular, we only support one value of signalg currently; so let's check the signalg field in the downcall (in case we decide there's something else we could support here eventually), but ignore it otherwise. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 03 12月, 2006 1 次提交
-
-
由 Arnaldo Carvalho de Melo 提交于
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
-
- 21 9月, 2006 1 次提交
-
-
由 Herbert Xu 提交于
This patch converts SUNRPC/GSS to use the new block cipher type where applicable. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 22 7月, 2006 1 次提交
-
-
由 Panagiotis Issaris 提交于
Signed-off-by: NPanagiotis Issaris <takis@issaris.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 6月, 2006 1 次提交
-
-
由 Andreas Mohr 提交于
acquired (aquired) contiguous (contigious) successful (succesful, succesfull) surprise (suprise) whether (weather) some other misspellings Signed-off-by: NAndreas Mohr <andi@lisas.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 07 1月, 2006 1 次提交
-
-
由 J. Bruce Fields 提交于
Print messages when an unsupported encrytion algorthm is requested or there is an error locating a supported algorthm. Signed-off-by: NKevin Coffman <kwc@citi.umich.edu> Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 19 10月, 2005 4 次提交
-
-
由 J. Bruce Fields 提交于
Remove some senseless wrappers. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 J. Bruce Fields 提交于
Not only are the qop parameters that are passed around throughout the gssapi unused by any currently implemented mechanism, but there appears to be some doubt as to whether they will ever be used. Let's just kill them off for now. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 J. Bruce Fields 提交于
Add support for privacy to the krb5 rpcsec_gss mechanism. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 J. Bruce Fields 提交于
The code this was originally derived from processed wrap and mic tokens using the same functions. This required some contortions, and more would be required with the addition of xdr_buf's, so it's better to separate out the two code paths. In preparation for adding privacy support, remove the last vestiges of the old wrap token code. Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 24 9月, 2005 1 次提交
-
-
由 Chuck Lever 提交于
Clean-up: get rid of unnecessary socket.h and in.h includes in the generic parts of the RPC client. Test-plan: Compile kernel with CONFIG_NFS enabled. Version: Thu, 11 Aug 2005 16:06:23 -0400 Signed-off-by: NChuck Lever <cel@netapp.com> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 02 9月, 2005 1 次提交
-
-
由 Jesper Juhl 提交于
Since the patch to add a NULL short-circuit to crypto_free_tfm() went in, there's no longer any need for callers of that function to check for NULL. This patch removes the redundant NULL checks and also a few similar checks for NULL before calls to kfree() that I ran into while doing the crypto_free_tfm bits. I've succesfuly compile tested this patch, and a kernel with the patch applied boots and runs just fine. When I posted the patch to LKML (and other lists/people on Cc) it drew the following comments : J. Bruce Fields commented "I've no problem with the auth_gss or nfsv4 bits.--b." Sridhar Samudrala said "sctp change looks fine." Herbert Xu signed off on the patch. So, I guess this is ready to be dropped into -mm and eventually mainline. Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-