summaryrefslogtreecommitdiff
path: root/src/backend/libpq/be-secure-gssapi.c
AgeCommit message (Collapse)Author
2020-05-05Fix severe memory leaks in GSSAPI encryption support.Tom Lane
Both the backend and libpq leaked buffers containing encrypted data to be transmitted, so that the process size would grow roughly as the total amount of data sent. There were also far-less-critical leaks of the same sort in GSSAPI session establishment. Oversight in commit b0b39f72b, which I failed to notice while reviewing the code in 2c0cdc818. Per complaint from pmc@citylink. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200504115649.GA77072@gate.oper.dinoex.org
2020-01-11Extensive code review for GSSAPI encryption mechanism.Tom Lane
Fix assorted bugs in handling of non-blocking I/O when using GSSAPI encryption. The encryption layer could return the wrong status information to its caller, resulting in effectively dropping some data (or possibly in aborting a not-broken connection), or in a "livelock" situation where data remains to be sent but the upper layers think transmission is done and just go to sleep. There were multiple small thinkos contributing to that, as well as one big one (failure to think through what to do when a send fails after having already transmitted data). Note that these errors could cause failures whether the client application asked for non-blocking I/O or not, since both libpq and the backend always run things in non-block mode at this level. Also get rid of use of static variables for GSSAPI inside libpq; that's entirely not okay given that multiple connections could be open at once inside a single client process. Also adjust a bunch of random small discrepancies between the frontend and backend versions of the send/receive functions -- except for error handling, they should be identical, and now they are. Also extend the Kerberos TAP tests to exercise cases where nontrivial amounts of data need to be pushed through encryption. Before, those tests didn't provide any useful coverage at all for the cases of interest here. (They still might not, depending on timing, but at least there's a chance.) Per complaint from pmc@citylink and subsequent investigation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200109181822.GA74698@gate.oper.dinoex.org
2020-01-01Update copyrights for 2020Bruce Momjian
Backpatch-through: update all files in master, backpatch legal files through 9.4
2019-09-19GSSAPI error message improvementsPeter Eisentraut
Make the error messages around GSSAPI encryption a bit clearer. Tweak some messages to avoid plural problems. Also make a code change for clarity. Using "conf" for "confidential" is quite confusing. Using "conf_state" is perhaps not much better but that's what the GSSAPI documentation uses, so there is at least some hope of understanding it.
2019-06-29Remove unnecessary header from be-secure-gssapi.cMichael Paquier
libpq/libpq-be.h is included by libpq/libpq.h so there is no need to explicitly include it separately. Author: Daniel Gustafsson Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/A4852E46-9ED1-4861-A23B-22A83E34A084@yesql.se
2019-06-14Fix typos and inconsistencies in code commentsMichael Paquier
Author: Alexander Lakhin Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com
2019-06-08Move be-gssapi-common.h into src/include/libpq/Michael Paquier
The file has been introduced in src/backend/libpq/ as of b0b39f72, but all backend-side headers of libpq are located in src/include/libpq/. Note that the identification path on top of the file referred to src/include/libpq/ from the start. Author: Michael Paquier Reviewed-by: Stephen Frost Discussion: https://postgr.es/m/20190607043415.GE1736@paquier.xyz
2019-05-24Update copyright year.Thomas Munro
Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com
2019-04-17Fix assorted minor bogosity in GSSAPI transport error messages.Tom Lane
I noted that some buildfarm members were complaining about %ld being used to format values that are (probably) declared size_t. Use %zu instead, and insert a cast just in case some versions of the GSSAPI API declare the length field differently. While at it, clean up gratuitous differences in wording of equivalent messages, show the complained-of length in all relevant messages not just some, include trailing newline where needed, adjust random deviations from project-standard code layout and message style, etc.
2019-04-03GSSAPI encryption supportStephen Frost
On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com