pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feed[PATCH] clarify username mapping in Kerberos and GSSAPI
7+ messages / 4 participants
[nested] [flat]
Commits from this thread:
2020-10-03 472e518a44 8075f3f2f8 fa05c22879 d449ec6d52 f1b2b119cf 934bb65fdf 566c6d4fd8 doc: clarify the use of ssh port forwarding
* [PATCH] clarify username mapping in Kerberos and GSSAPI
@ 2009-10-23 19:43 Turner, Ian <Ian.Turner@deshaw.com>
2010-02-20 19:21 ` Re: [PATCH] clarify username mapping in Kerberos and GSSAPI Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 7+ messages in thread
From: Turner, Ian @ 2009-10-23 19:43 UTC (permalink / raw)
To: pgsql-docs
Hello all,
I noticed what appears to be an ambiguity in this area, so I prepared a patch. It is included below. The issue is that the documentation does not make it crystal clear exactly what string is used for username mapping when authenticating with GSSAPI or Kerberos. It's possible that this issue also applies to the SSPI documentation, though I didn't check.
Cheers,
--Ian Turner
Senior UNIX Systems Engineer
D. E. Shaw & Co.
inline patch 1: postgresql-8.4-8.4.1-docfix/doc/src/sgml/client-auth.sgml (+17/-12 lines) download inline-1.patch
--- postgresql-8.4-8.4.1/doc/src/sgml/client-auth.sgml 2009-06-24 14:46:32.000000000 +0100
+++ postgresql-8.4-8.4.1-docfix/doc/src/sgml/client-auth.sgml 2009-10-23 20:41:28.000000000 +0100
@@ -801,23 +801,28 @@
The following configuration options are supported for <productname>GSSAPI</productname>:
<variablelist>
<varlistentry>
- <term><literal>map</literal></term>
+ <term><literal>include_realm</literal></term>
<listitem>
<para>
- Allows for mapping between system and database usernames. See
- <xref linkend="auth-username-maps"> for details.
+ If set to <literal>1</>, the realm name from the authenticated user
+ principal is included in the system user name that's passed through
+ username mapping (<xref linkend="auth-username-maps">). This is
+ useful for handling users from multiple realms.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><literal>include_realm</literal></term>
+ <term><literal>map</literal></term>
<listitem>
<para>
- If set to <literal>1</>, the realm name from the authenticated user
- principal is included in the system user name that's passed through
- username mapping (<xref linkend="auth-username-maps">). This is
- useful for handling users from multiple realms.
+ Allows for mapping between system and database usernames. See
+ <xref linkend="auth-username-maps"> for details. For a Kerboros
+ principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
+ username used for mapping is <literal>username/hostbased</literal>
+ if <literal>include_realm</literal> is disabled, and
+ <literal>username/hostbased@EXAMPLE.COM</literal> if
+ <literal>include_realm</literal> is enabled.
</para>
</listitem>
</varlistentry>
@@ -1003,10 +1008,10 @@
<para>
When connecting to the database make sure you have a ticket for a
principal matching the requested database user name. For example, for
- database user name <literal>fred</>, both principal
- <literal>fred@EXAMPLE.COM</> and
- <literal>fred/users.example.com@EXAMPLE.COM</> could be used to
- authenticate to the database server.
+ database user name <literal>fred</>, principal
+ <literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
+ principle <literal>fred/users.example.com@EXAMPLE.COM</>, use a username
+ map, as described in <xref linkend="auth-username-maps">.
</para>
<para>
* Re: [PATCH] clarify username mapping in Kerberos and GSSAPI
2009-10-23 19:43 [PATCH] clarify username mapping in Kerberos and GSSAPI Turner, Ian <Ian.Turner@deshaw.com>
@ 2010-02-20 19:21 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 7+ messages in thread
From: Bruce Momjian @ 2010-02-20 19:21 UTC (permalink / raw)
To: Turner, Ian <Ian.Turner@deshaw.com>; +Cc: pgsql-docs
Thanks, applied.
---------------------------------------------------------------------------
Turner, Ian wrote:
> Hello all,
>
> I noticed what appears to be an ambiguity in this area, so I prepared a patch. It is included below. The issue is that the documentation does not make it crystal clear exactly what string is used for username mapping when authenticating with GSSAPI or Kerberos. It's possible that this issue also applies to the SSPI documentation, though I didn't check.
>
> Cheers,
>
> --Ian Turner
> Senior UNIX Systems Engineer
> D. E. Shaw & Co.
>
> --- postgresql-8.4-8.4.1/doc/src/sgml/client-auth.sgml 2009-06-24 14:46:32.000000000 +0100
> +++ postgresql-8.4-8.4.1-docfix/doc/src/sgml/client-auth.sgml 2009-10-23 20:41:28.000000000 +0100
> @@ -801,23 +801,28 @@
> The following configuration options are supported for <productname>GSSAPI</productname>:
> <variablelist>
> <varlistentry>
> - <term><literal>map</literal></term>
> + <term><literal>include_realm</literal></term>
> <listitem>
> <para>
> - Allows for mapping between system and database usernames. See
> - <xref linkend="auth-username-maps"> for details.
> + If set to <literal>1</>, the realm name from the authenticated user
> + principal is included in the system user name that's passed through
> + username mapping (<xref linkend="auth-username-maps">). This is
> + useful for handling users from multiple realms.
> </para>
> </listitem>
> </varlistentry>
>
> <varlistentry>
> - <term><literal>include_realm</literal></term>
> + <term><literal>map</literal></term>
> <listitem>
> <para>
> - If set to <literal>1</>, the realm name from the authenticated user
> - principal is included in the system user name that's passed through
> - username mapping (<xref linkend="auth-username-maps">). This is
> - useful for handling users from multiple realms.
> + Allows for mapping between system and database usernames. See
> + <xref linkend="auth-username-maps"> for details. For a Kerboros
> + principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
> + username used for mapping is <literal>username/hostbased</literal>
> + if <literal>include_realm</literal> is disabled, and
> + <literal>username/hostbased@EXAMPLE.COM</literal> if
> + <literal>include_realm</literal> is enabled.
> </para>
> </listitem>
> </varlistentry>
> @@ -1003,10 +1008,10 @@
> <para>
> When connecting to the database make sure you have a ticket for a
> principal matching the requested database user name. For example, for
> - database user name <literal>fred</>, both principal
> - <literal>fred@EXAMPLE.COM</> and
> - <literal>fred/users.example.com@EXAMPLE.COM</> could be used to
> - authenticate to the database server.
> + database user name <literal>fred</>, principal
> + <literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
> + principle <literal>fred/users.example.com@EXAMPLE.COM</>, use a username
> + map, as described in <xref linkend="auth-username-maps">.
> </para>
>
> <para>
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 7+ messages in thread
* small clairifcation
@ 2020-08-27 16:18 PG Doc comments form <noreply@postgresql.org>
2020-08-28 04:51 ` Re: small clairifcation David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: PG Doc comments form @ 2020-08-27 16:18 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: karimelghazouly@gmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html
Description:
"The first number in the -L argument, 63333, is the port number of your end
of the tunnel; it can be any unused port. (IANA reserves ports 49152 through
65535 for private use.) The second number, 5432, is the remote end of the
tunnel: the port number your server is using. "
as a beginner This took me some time to understand what do you mean by "your
server" "your end of the tunnel "
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: small clairifcation
2020-08-27 16:18 small clairifcation PG Doc comments form <noreply@postgresql.org>
@ 2020-08-28 04:51 ` David G. Johnston <david.g.johnston@gmail.com>
2020-09-01 00:42 ` Re: small clairifcation Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 7+ messages in thread
From: David G. Johnston @ 2020-08-28 04:51 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: karimelghazouly@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Thu, Aug 27, 2020 at 6:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> PG Doc comments form <noreply@postgresql.org> writes:
> > The following documentation comment has been logged on the website:
> > Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html
> > Description:
>
> > "The first number in the -L argument, 63333, is the port number of your
> end
> > of the tunnel; it can be any unused port. (IANA reserves ports 49152
> through
> > 65535 for private use.) The second number, 5432, is the remote end of the
> > tunnel: the port number your server is using. "
>
> > as a beginner This took me some time to understand what do you mean by
> "your
> > server" "your end of the tunnel "
>
> Hm, do you have a suggestion for better wording?
>
>
I agree on the need for a different perspective here since it reads just
fine once you know what it is talking about.
But absent that maybe a slightly more tutorial flow would be good.
```
First make sure you can connect to the remote machine that is able to
access the PostgreSQL server (in this example the PostgreSQL server is
running on said remote machine).
local> ssh joe@foo.com
Once connected, confirm that while on that machine you are able to connect
to the PostgreSQL server via psql.
remote> psql -h localhost -p 5432 postgres
Now that we have confirmed that the two seperate parts are working, the ssh
connection and the psql connection, we can create a tunnel so that we can
execute psql on our local machine but have the PostgreSQL server see the
inbound connection as coming from the remote machine. To do this we need
to set up a server-like process on the local machine to accept the
connection from psql and then transmit the data to the remote machine.
Since psql is looking for a port number to connect to, 5432 when executed
on the remote machine, we need to specify which one to use on the local
machine. For this example we choose 63333 (it can be any number between
49152 and 65535, and must not be in use already [footnote if more detail is
desired]). We are, in effect, merging the ssh and psql commands above into
a hybrid command that maps the remote psql location information to a local
address and port. ssh, in this tunnel mode, always just listens to its
loopback address so only the local port (6333) is required; but both the
remote host (which is using its own loopback address - the localhost thus
refers to this) and port (5432) are needed as that end of the tunnel can
point anywhere visible to the remote machine (foo.com).
local> ssh -L 63333:localhost:5432 joe@foo.com
Now we locally launch psql, connecting to localhost:63333, and ssh on
foo.com proxies the stream to its localhost:5432 connection.
local> psql -h localhost -p 63333
```
I haven't considered how or whether the more advanced details would change
if we expand upon and reword the basic section to be more like the above.
I am curious about whether and why this method absolutely guarantees that
the resultant connection within the tunnel is not SSL-encrypted.
David J.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: small clairifcation
2020-08-27 16:18 small clairifcation PG Doc comments form <noreply@postgresql.org>
2020-08-28 04:51 ` Re: small clairifcation David G. Johnston <david.g.johnston@gmail.com>
@ 2020-09-01 00:42 ` Bruce Momjian <bruce@momjian.us>
2020-10-03 01:40 ` Re: small clairifcation Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 7+ messages in thread
From: Bruce Momjian @ 2020-09-01 00:42 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; karimelghazouly@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Thu, Aug 27, 2020 at 09:51:49PM -0700, David G. Johnston wrote:
> On Thu, Aug 27, 2020 at 6:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> PG Doc comments form <noreply@postgresql.org> writes:
> > The following documentation comment has been logged on the website:
> > Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html
> > Description:
>
> > "The first number in the -L argument, 63333, is the port number of your
> end
> > of the tunnel; it can be any unused port. (IANA reserves ports 49152
> through
> > 65535 for private use.) The second number, 5432, is the remote end of the
> > tunnel: the port number your server is using. "
>
> > as a beginner This took me some time to understand what do you mean by
> "your
> > server" "your end of the tunnel "
>
> Hm, do you have a suggestion for better wording?
>
>
>
> I agree on the need for a different perspective here since it reads just fine
> once you know what it is talking about.
>
> But absent that maybe a slightly more tutorial flow would be good.
I didn't think a tutorial flow was the right thing to here, so I
reworded the section to be more details and have a clearer flow ---
patch attached.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachments:
ssh.diff (text/x-diff, 3.9K) download
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 6cda39f3ab..bc68ddc94b 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2548,34 +2548,39 @@ openssl x509 -req -in server.csr -text -days 365 \
First make sure that an <application>SSH</application> server is
running properly on the same machine as the
<productname>PostgreSQL</productname> server and that you can log in using
- <command>ssh</command> as some user. Then you can establish a secure
- tunnel with a command like this from the client machine:
+ <command>ssh</command> as some user; you then can establish a
+ secure tunnel to the remote server. A secure tunnel listens on a
+ local port and forwards all traffic to a port on the remote machine.
+ Traffic sent to the remote port can arrive on its
+ <literal>localhost</literal> address, or different bind
+ address if desired; it does not appear as coming from your
+ local machine. This command creates a secure tunnel from the client
+ machine to the remote machine <literal>foo.com</literal>:
<programlisting>
ssh -L 63333:localhost:5432 joe@foo.com
</programlisting>
The first number in the <option>-L</option> argument, 63333, is the
- port number of your end of the tunnel; it can be any unused port.
- (IANA reserves ports 49152 through 65535 for private use.) The
- second number, 5432, is the remote end of the tunnel: the port
- number your server is using. The name or IP address between the
- port numbers is the host with the database server you are going to
- connect to, as seen from the host you are logging in to, which
- is <literal>foo.com</literal> in this example. In order to connect
- to the database server using this tunnel, you connect to port 63333
- on the local machine:
+ local port number of the tunnel; it can be any unused port. (IANA
+ reserves ports 49152 through 65535 for private use.) The name or IP
+ address after this is the remote bind address you are connecting to,
+ i.e., <literal>localhost</literal>, which is the default. The second
+ number, 5432, is the remote end of the tunnel, e.g., the port number
+ your database server is using. In order to connect to the database
+ server using this tunnel, you connect to port 63333 on the local
+ machine:
<programlisting>
psql -h localhost -p 63333 postgres
</programlisting>
- To the database server it will then look as though you are really
+ To the database server it will then look as though you are
user <literal>joe</literal> on host <literal>foo.com</literal>
- connecting to <literal>localhost</literal> in that context, and it
+ connecting to the <literal>localhost</literal> bind address, and it
will use whatever authentication procedure was configured for
- connections from this user and host. Note that the server will not
+ connections by that user to that bind address. Note that the server will not
think the connection is SSL-encrypted, since in fact it is not
encrypted between the
<application>SSH</application> server and the
<productname>PostgreSQL</productname> server. This should not pose any
- extra security risk as long as they are on the same machine.
+ extra security risk because they are on the same machine.
</para>
<para>
@@ -2587,12 +2592,12 @@ psql -h localhost -p 63333 postgres
</para>
<para>
- You could also have set up the port forwarding as
+ You could also have set up port forwarding as
<programlisting>
ssh -L 63333:foo.com:5432 joe@foo.com
</programlisting>
but then the database server will see the connection as coming in
- on its <literal>foo.com</literal> interface, which is not opened by
+ on its <literal>foo.com</literal> bind address, which is not opened by
the default setting <literal>listen_addresses =
'localhost'</literal>. This is usually not what you want.
</para>
* Re: small clairifcation
2020-08-27 16:18 small clairifcation PG Doc comments form <noreply@postgresql.org>
2020-08-28 04:51 ` Re: small clairifcation David G. Johnston <david.g.johnston@gmail.com>
2020-09-01 00:42 ` Re: small clairifcation Bruce Momjian <bruce@momjian.us>
@ 2020-10-03 01:40 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 7+ messages in thread
From: Bruce Momjian @ 2020-10-03 01:40 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; karimelghazouly@gmail.com, Pg Docs <pgsql-docs@lists.postgresql.org>
On Mon, Aug 31, 2020 at 08:42:57PM -0400, Bruce Momjian wrote:
> On Thu, Aug 27, 2020 at 09:51:49PM -0700, David G. Johnston wrote:
> > On Thu, Aug 27, 2020 at 6:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > PG Doc comments form <noreply@postgresql.org> writes:
> > > The following documentation comment has been logged on the website:
> > > Page: https://www.postgresql.org/docs/9.5/ssh-tunnels.html
> > > Description:
> >
> > > "The first number in the -L argument, 63333, is the port number of your
> > end
> > > of the tunnel; it can be any unused port. (IANA reserves ports 49152
> > through
> > > 65535 for private use.) The second number, 5432, is the remote end of the
> > > tunnel: the port number your server is using. "
> >
> > > as a beginner This took me some time to understand what do you mean by
> > "your
> > > server" "your end of the tunnel "
> >
> > Hm, do you have a suggestion for better wording?
> >
> >
> >
> > I agree on the need for a different perspective here since it reads just fine
> > once you know what it is talking about.
> >
> > But absent that maybe a slightly more tutorial flow would be good.
>
> I didn't think a tutorial flow was the right thing to here, so I
> reworded the section to be more details and have a clearer flow ---
> patch attached.
Patch applied to all supported versions. Thanks for the report.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2020-10-03 01:40 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-10-23 19:43 [PATCH] clarify username mapping in Kerberos and GSSAPI Turner, Ian <Ian.Turner@deshaw.com>
2010-02-20 19:21 ` Bruce Momjian <bruce@momjian.us>
2020-08-27 16:18 small clairifcation PG Doc comments form <noreply@postgresql.org>
2020-08-28 04:51 ` Re: small clairifcation David G. Johnston <david.g.johnston@gmail.com>
2020-09-01 00:42 ` Re: small clairifcation Bruce Momjian <bruce@momjian.us>
2020-10-03 01:40 ` Re: small clairifcation Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox