Re: [PATCHES] Allow IDENT authentication on local connections (Linux only)

[ redirected to pgsql-hackers for comment ]

Helge Bahmann <bahmann@math.tu-freiberg.de> writes:

On Tue, 31 Jul 2001, Tom Lane wrote:

There is a more complete version of this capability in the Debian patch
set. I think we've been waiting for Oliver to pull it out and submit it
as a patch...

Ok found it; uses "peer" as a keyword instead of "ident" but basically
does the same thing. I think you can discard my patch then.

Well, we need to talk about that. I like your idea of making ident auth
"just work" on local connections better than Oliver's approach of
inventing a separate auth-type keyword. So some kind of merger of the
two patches seems attractive to me. But Oliver may feel that he has to
continue to support the "peer" keyword on Debian anyway, for backwards
compatibility. If so, do we want different ways of doing the same thing
on different distros, or should we just follow the Debian precedent to
keep things ugly-but-consistent?

We could easily just accept peer as a synonym for ident for a few
releases, because it fact our ident will become something that is used
beyond the identd server.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... But Oliver may feel that he has to
continue to support the "peer" keyword on Debian anyway, for backwards
compatibility. If so, do we want different ways of doing the same thing
on different distros, or should we just follow the Debian precedent to
keep things ugly-but-consistent?

We could easily just accept peer as a synonym for ident for a few
releases,

Or let Oliver patch the Debian package to accept peer as a synonym for
ident. I don't see any real need to encourage the use of that keyword
by non-Debianers...

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

... But Oliver may feel that he has to
continue to support the "peer" keyword on Debian anyway, for backwards
compatibility. If so, do we want different ways of doing the same thing
on different distros, or should we just follow the Debian precedent to
keep things ugly-but-consistent?

We could easily just accept peer as a synonym for ident for a few
releases,

Or let Oliver patch the Debian package to accept peer as a synonym for
ident. I don't see any real need to encourage the use of that keyword
by non-Debianers...

Good idea. I was hoping to reduce his patching but this way he can
control how long he keeps it active. However, the text is only one line
in hba.c. Either way is fine.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tom Lane wrote:

[ redirected to pgsql-hackers for comment ]

Helge Bahmann <bahmann@math.tu-freiberg.de> writes:

On Tue, 31 Jul 2001, Tom Lane wrote:

There is a more complete version of this capability in the Debian patch
set. I think we've been waiting for Oliver to pull it out and submit it
as a patch...

Ok found it; uses "peer" as a keyword instead of "ident" but basically
does the same thing. I think you can discard my patch then.

Well, we need to talk about that. I like your idea of making ident auth
"just work" on local connections better than Oliver's approach of
inventing a separate auth-type keyword. So some kind of merger of the
two patches seems attractive to me. But Oliver may feel that he has to
continue to support the "peer" keyword on Debian anyway, for backwards
compatibility. If so, do we want different ways of doing the same thing
on different distros, or should we just follow the Debian precedent to
keep things ugly-but-consistent?

This change has only been made in the unstable release; so I don't mind
if peer and ident are folded together. Anyone running unstable knows
the world may turn upside down beneath him!

So if you have a patch to do that, go ahead.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Have not I commanded thee? Be strong and of a good
courage; be not afraid, neither be thou dismayed; for
the LORD thy God is with thee whithersoever thou
goest." Joshua 1:9

"Oliver Elphick" <olly@lfix.co.uk> writes:

This change has only been made in the unstable release; so I don't mind
if peer and ident are folded together. Anyone running unstable knows
the world may turn upside down beneath him!

So if you have a patch to do that, go ahead.

Sounds great. Helge, the main things your patch was missing were
autoconf support and documentation fixes. Do you want to add those
(possibly stealing liberally from the Debian patches) and resubmit?

BTW, Bruce has recently committed some wholesale changes in hba.c, so a
patch against 7.1.2 likely won't apply cleanly. If you could do your
patch as a diff against CVS tip, it'd ease applying it.

regards, tom lane

"Oliver Elphick" <olly@lfix.co.uk> writes:

This change has only been made in the unstable release; so I don't mind
if peer and ident are folded together. Anyone running unstable knows
the world may turn upside down beneath him!

So if you have a patch to do that, go ahead.

Sounds great. Helge, the main things your patch was missing were
autoconf support and documentation fixes. Do you want to add those
(possibly stealing liberally from the Debian patches) and resubmit?

BTW, Bruce has recently committed some wholesale changes in hba.c, so a
patch against 7.1.2 likely won't apply cleanly. If you could do your
patch as a diff against CVS tip, it'd ease applying it.

I can merge into hba.conf if needed.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Can you send over your version for review. We can edit the 'peer' part.

Tom Lane wrote:

[ redirected to pgsql-hackers for comment ]

Helge Bahmann <bahmann@math.tu-freiberg.de> writes:

On Tue, 31 Jul 2001, Tom Lane wrote:

There is a more complete version of this capability in the Debian patch
set. I think we've been waiting for Oliver to pull it out and submit it
as a patch...

Ok found it; uses "peer" as a keyword instead of "ident" but basically
does the same thing. I think you can discard my patch then.

Well, we need to talk about that. I like your idea of making ident auth
"just work" on local connections better than Oliver's approach of
inventing a separate auth-type keyword. So some kind of merger of the
two patches seems attractive to me. But Oliver may feel that he has to
continue to support the "peer" keyword on Debian anyway, for backwards
compatibility. If so, do we want different ways of doing the same thing
on different distros, or should we just follow the Debian precedent to
keep things ugly-but-consistent?

This change has only been made in the unstable release; so I don't mind
if peer and ident are folded together. Anyone running unstable knows
the world may turn upside down beneath him!

So if you have a patch to do that, go ahead.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Have not I commanded thee? Be strong and of a good
courage; be not afraid, neither be thou dismayed; for
the LORD thy God is with thee whithersoever thou
goest." Joshua 1:9

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

BTW, while digging through my mail archives I discovered that Oliver
*did* already extract his "peer" auth patch and submit it as a proposed
patch --- see the pghackers archives for 3-May-2001. At the time I
think we were concerned about portability issues, but as long as it's
appropriately autoconf'd and documented, I see no real objection to
supporting SO_PEERCRED authentication.

I do still like Helge's API (use "ident") better than adding another
auth keyword, though.

regards, tom lane

BTW, while digging through my mail archives I discovered that Oliver
*did* already extract his "peer" auth patch and submit it as a proposed
patch --- see the pghackers archives for 3-May-2001. At the time I
think we were concerned about portability issues, but as long as it's
appropriately autoconf'd and documented, I see no real objection to
supporting SO_PEERCRED authentication.

I do still like Helge's API (use "ident") better than adding another
auth keyword, though.

There is a Solaris API someone submitted a a month ago that was sort of
rejected too. I will have to dig that one up.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

BTW, while digging through my mail archives I discovered that Oliver
*did* already extract his "peer" auth patch and submit it as a proposed
patch --- see the pghackers archives for 3-May-2001. At the time I
think we were concerned about portability issues, but as long as it's
appropriately autoconf'd and documented, I see no real objection to
supporting SO_PEERCRED authentication.

I do still like Helge's API (use "ident") better than adding another
auth keyword, though.

Can someone find the Solaris patch submitted a few months ago that did a
similar thing? I can't seem to find it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Can someone find the Solaris patch submitted a few months ago that did a
similar thing? I can't seem to find it.

I couldn't find one either. I found a couple of unsupported assertions
that Solaris and *BSD had SO_PEERCRED, so the Linux patch might work
for them. We'll find out soon enough, I suppose.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Can someone find the Solaris patch submitted a few months ago that did a
similar thing? I can't seem to find it.

I couldn't find one either. I found a couple of unsupported assertions
that Solaris and *BSD had SO_PEERCRED, so the Linux patch might work
for them. We'll find out soon enough, I suppose.

Not here on BSD/OS. I know I saw a Solaris patch that did exactly this
and I questioned it because it was only for Solaris. Now that I
research and I see different OS's doing this different ways, and I have
mucked up hba.c already, it seemed like a good patch.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Not here on BSD/OS. I know I saw a Solaris patch that did exactly this
and I questioned it because it was only for Solaris. Now that I
research and I see different OS's doing this different ways, and I have
mucked up hba.c already, it seemed like a good patch.

Well, if someone can come up with a way to do the same thing on other
platforms, we can easily fold it in.

Now that I think about it, it's silly to #ifdef SO_PEERCRED in three
places. We can reduce that to one place: make ident_unix always exist,
and have it do the test for supported-or-not:

#ifdef SO_PEERCRED
do it the Linux way
#else
report error "IDENT not supported on local connections"
#endif

Then adding variants for other platforms is just a matter of more ifdefs
in the one place. I'll take care of doing this in a little bit...

BTW, a question for Linuxers: Oliver's older patch did
setsockopt(SO_PASSCRED) before getsockopt(SO_PEERCRED), whereas Helge's
version did not. I included the PASSCRED step in what I committed,
because the Linux docs I had at hand implied it was needed. But
evidently it worked without it for Helge. Is there some variation among
Linux versions as to whether PASSCRED is enabled by default?

regards, tom lane

Helge Bahmann <bahmann@math.tu-freiberg.de> writes:

Most certainly they do not, or at least it is called differently; I
grepped includes of: FreeBSD 4.2, Solaris 8, Irix 6.5 and AIX (4.3?) and
did not find SO_PEERCRED.

On FreeBSD (and I guess Solaris as well) it is possible to pass
credentials using ancillary messages (Linux works as well, so this
approach would be significantly more portable). However this requires the
cooperation of the client who has to actively *send* his credentials, so
this would require changes to both the backend and libpq.

Ah, now I understand: those references I saw mention the existence of
the underlying SCM_CREDENTIALS (or whatever it's called) message type,
not the SO_PEERCRED getsockopt facility.

I agree that it's not worth pursuing at the moment. A localized change
in the backend is one thing, but an OS-specific addition to our client-
visible authentication protocol would be a lot bigger change, and a lot
more debatable. If we get a larger/more active Solaris user community,
maybe someone will be motivated to do it.

regards, tom lane

Ah, now I understand: those references I saw mention the existence of
the underlying SCM_CREDENTIALS (or whatever it's called) message type,
not the SO_PEERCRED getsockopt facility.

Yes! That was it the Solaris patch I remember, SCM_CREDENTIALS.

I agree that it's not worth pursuing at the moment. A localized change
in the backend is one thing, but an OS-specific addition to our client-
visible authentication protocol would be a lot bigger change, and a lot
more debatable. If we get a larger/more active Solaris user community,
maybe someone will be motivated to do it.

Yes. It is part of that whole SvR4 API that allowed you to push file
descriptors to other processes and stuff like that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Thu, 2 Aug 2001, Bruce Momjian wrote:

Yes! That was it the Solaris patch I remember, SCM_CREDENTIALS.

Can you provide a pointer to this patch? I just grepped Solaris includes
in vain for SCM_CRED.

The keyword "SCM_CREDENTIALS" is actually used by Linux, whereas FreeBSD
uses "SCM_CREDS", so perhaps you are mistaken and the patch was for either
Linux or BSD instead of Solaris?

Found it:

http://fts.postgresql.org/db/mw/msg.html?mid=115140

See the entire thread for the comments about it.

He says Linux and BSD support it, and that it was invented by Solaris.
I see SCM_CREDS on BSD/OS. I wonder if this is what we should use
instead of the PEER define we just added?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Found it:
http://fts.postgresql.org/db/mw/msg.html?mid=115140
See the entire thread for the comments about it.

That patch uses SO_PEERCRED, and is the direct ancestor of the
present Debian patches. I haven't seen any code go by that uses
the SCM_CREDS message directly.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Found it:
http://fts.postgresql.org/db/mw/msg.html?mid=115140
See the entire thread for the comments about it.

That patch uses SO_PEERCRED, and is the direct ancestor of the
present Debian patches. I haven't seen any code go by that uses
the SCM_CREDS message directly.

Bummer.
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tom Lane writes:

Well, we need to talk about that. I like your idea of making ident auth
"just work" on local connections better than Oliver's approach of
inventing a separate auth-type keyword.

This is exactly what I would not like to see. "ident" defines a specific
protocol, with an ident server. ident over something not TCP/IP doesn't
make sense, it could confuse admins. Just because it works similar
doesn't mean it is the same. In particular, the security issues are
completely different.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:

Well, we need to talk about that. I like your idea of making ident auth
"just work" on local connections better than Oliver's approach of
inventing a separate auth-type keyword.

This is exactly what I would not like to see. "ident" defines a specific
protocol, with an ident server. ident over something not TCP/IP doesn't
make sense, it could confuse admins. Just because it works similar
doesn't mean it is the same. In particular, the security issues are
completely different.

Well, ISTM this is a documentation issue. We've already committed the
patch using "ident" as the keyword, so I'd prefer to leave it that way
and improve the docs as necessary.

regards, tom lane

PS: welcome back! Hope you had a pleasant vacation.

Tom Lane writes:

Well, we need to talk about that. I like your idea of making ident auth
"just work" on local connections better than Oliver's approach of
inventing a separate auth-type keyword.

This is exactly what I would not like to see. "ident" defines a specific
protocol, with an ident server. ident over something not TCP/IP doesn't
make sense, it could confuse admins. Just because it works similar
doesn't mean it is the same. In particular, the security issues are
completely different.

Peter has a point here. The only way to save the 'ident' keyword is to
make it mean 'auto-identify' rather than identd.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026