gss-proxy.git/proxy/src/client, branch ntlmssp

Use gp_strerror() everywhere instead of strerror()

2013-11-22T13:41:24+00:00

https://fedorahosted.org/gss-proxy/ticket/111

Reviewed-by: Günther Deschner

Use secure_getenv in client and mechglue module

2013-11-21T12:48:25+00:00

proxymehc.so may be used in setuid binaries so follow best security
practices and use secure_getenv() if available.
Fallback to poorman emulation when secure_getenv() is not available.

Resolves: https://fedorahosted.org/gss-proxy/ticket/110

Reviewed-by: Günther Deschner

Fix continuations in context establishment calls

2013-11-19T13:34:47+00:00

Properly support continuations, including returning the rigth error code
and exporting partial contexts.

Fixes multistep authentications in particular for the initialization case
which always uses continuations.

Resolves: https://fedorahosted.org/gss-proxy/ticket/108

Reviewed-by: Günther Deschner

Preserve requested flags and lifetime

2013-11-19T13:02:42+00:00

These arguments have been accidentally forgotten causing failures for
applications that specify non default flags and non indefinite lifetime.

https://fedorahosted.org/gss-proxy/ticket/106

Reviewed-by: Günther Deschner

Fix resource leak in gpm_accept_sec_context().

2013-10-15T11:48:20+00:00

Resolves Coverity CID #12027.

Signed-off-by: Günther Deschner 
Reviewed-by: Simo Sorce

Fix socket error handling.

2013-05-16T10:11:43+00:00

1. Grab the socket lock for the whole conversation.

We need to keep the lock until the whole conversation is over.
Otherwise we may have concurrency issues where communication gets intermixed
and errors in one thread can cause a thread to hang.

Here is what we observed:

thread 1: grabs lock and send a request.
thread 2: grabs lock and sends a request
server: thread 2 request causes a fatal error and the server close the
connection
thread 2: grabs the lock and waits for a reply.
thread 2: gets the error and returns to caller with it (connection is closed).
thread 1: grabs the lock (which reopens the closed channel) and reads ...
... forever as the server has already killed all the previous state.

2. Fail immediately on short reads for the initial 4 byte length header.

If the first 4 bytes do not come at once don't bother retrying. In 99.9% of the
cases what we are witnessing here is a fatal error from the proxy that closed
the socket. Reopening the scket cannot accomplish anything as the request sent
down the channel is tied to the specific socket, so once the socket is closed
there is no hope to ever get back a reply.

Signed-off-by: Simo Sorce 
Reviewed-by: Günther Deschner

Add support for per-service sockets

2013-04-23T19:02:50+00:00

This way different processes running as the same user can be configured as
different servervices

Signed-off-by: Simo Sorce 
Reviewed-by: Günther Deschner

Use send() in client library to avoid SIGPIPE

2013-04-03T20:39:11+00:00

The client library lives in applications that may not be blocking or ignoring
SIGPIPE. Using write() can cause SIGPIPE to be raised in the application if the
proxy is restarted. If the application does not catch the signal then it is
terminated.

Make sure this does not happen by using send() with the MSG_NOSIGNAL flag.

Signed-off-by: Simo Sorce

Fix missing break statement found by Coverity

2013-04-03T20:39:11+00:00

Signed-off-by: Simo Sorce

Fix infinite loop due to bad sign of variable

2013-04-03T20:39:11+00:00

Change the i variable to be a signed integer ot the loop will never end because
and unsigned integer decremented past 0 simply wraps to a very big integer.
The condition that would break the loop can never be true therefore the code
would loop forever until eventually a double free would cause a crash.

Found by Coverity.

Signed-off-by: Simo Sorce