Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Oliver Elphick olly@lfix.co.uk writes: The upstream developers are not friendly to non-portable features; I might be able to get it added under a config option. Thought so. My selling point is that this feature is completely optional: if it is compiled in, you're allowed to use a new authtype peer (or so) with the local transport in /etc/postgresql/pg_hba.conf. That's just like kerberos support which is also not enabled on all systems (and the krb[45] authtype is there or not, depending on that) This feature would work on all kernels that woody supports (Linux 2.2 and 2.4). Hurd support is an issue for the future, though. -- Robbe signature.ng Description: PGP signature
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Robert Bihlmeyer wrote: The upstream developers are not friendly to non-portable features; I might be able to get it added under a config option. Thought so. My selling point is that this feature is completely optional: if it is compiled in, you're allowed to use a new authtype peer (or so) with the local transport in /etc/postgresql/pg_hba.conf. That's just like kerberos support which is also not enabled on all systems (and the krb[45] authtype is there or not, depending on that) I have created this feature, using autoconf/configure to test if it is supported, and have sent a patch upstream. The feature will be in Debian anyway. -- Oliver Elphick[EMAIL PROTECTED] 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 Bless them which persecute you: bless, and curse not. Romans 12:14
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Robert Bihlmeyer wrote: Package: libpgsql2.1 Version: 7.1release-2 Severity: normal identds are considered mild privacy/security risks, therefore I don't think libpgsql2.1 and postgresql-client[1] should depend on ident-server. The main use seems to be to allow local connections without further authentication. A noble goal that should be reached via local transport instead. Maybe there's more reasoning why this dependency is necessary. In this case, please put it in the documentation. It is indeed the case that ident is needed to allow local access without a password. I understand that this presents a small security risk on the server. However, without it, it is necessary for the postgres administrator's database password to be held in clear in some file, so that the automatic clean-up processes will be able to operate. It seems to me that the obvious security risks of the latter process outweigh the minor risks of having ident available. However, it is only strictly necessary for the server to have ident available, so I propose to move the dependency from libpgsql2.1 (and postgresql-client) to postgresql itself. In case anyone should ask why the server cannot authenticate directly, communication between front- and back-ends is done through a Unix socket and therefore it is not possible for the back-end to know the identity of the user at the front-end. The only options for Unix socket access are password-protection or trust (that is, a completely open database). -- Oliver Elphick[EMAIL PROTECTED] 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 For whosoever will save his life shall lose it. But whosoever will lose his life for my sake, the same shall save it. Luke 9:24
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
On Mon, 30 Apr 2001, Oliver Elphick wrote:
Robert Bihlmeyer wrote:
Package: libpgsql2.1
Version: 7.1release-2
Severity: normal
identds are considered mild privacy/security risks, therefore I don't
think libpgsql2.1 and postgresql-client[1] should depend on
ident-server.
The main use seems to be to allow local connections without further
authentication. A noble goal that should be reached via local
transport instead.
Maybe there's more reasoning why this dependency is necessary. In this
case, please put it in the documentation.
It is indeed the case that ident is needed to allow local access without
a password. I understand that this presents a small security risk on the
server. However, without it, it is necessary for the postgres
administrator's database password to be held in clear in some file, so that
the automatic clean-up processes will be able to operate.
It seems to me that the obvious security risks of the latter process
outweigh the minor risks of having ident available. However, it is only
strictly necessary for the server to have ident available, so I propose to
move the dependency from libpgsql2.1 (and postgresql-client) to postgresql
itself.
In case anyone should ask why the server cannot authenticate directly,
communication between front- and back-ends is done through a Unix socket
and therefore it is not possible for the back-end to know the identity
of the user at the front-end. The only options for Unix socket access
are password-protection or trust (that is, a completely open database).
...
#include sys/socket.h
struct ucred peercred;
int so_len = sizeof(peercred);
retval = getsockopt(sock, SOL_SOCKET, SO_PEERCRED, peercred, so_len);
if (retval != 0 || so_len != sizeof(peercred)) {
/* We didn't get a valid credentials struct.
Close socket and continue. */
close(sock);
continue;
}
if (peercred.uid != ...) {
}
This works for Unix sockets under Linux 2.2 and Linux 2.4, at least. I don't
know how portable the interface is beyond that, and lack of portability might
prevent upstream from adopting it. It would be interesting to see this as an
option for Debian, though. (Does Hurd implement SO_PEERCRED?)
Steve Langasek
postmodern programmer
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Steve Langasek wrote: In case anyone should ask why the server cannot authenticate directly, communication between front- and back-ends is done through a Unix socket and therefore it is not possible for the back-end to know the identity of the user at the front-end. The only options for Unix socket access are password-protection or trust (that is, a completely open database). ... ... [code] ... This works for Unix sockets under Linux 2.2 and Linux 2.4, at least. I don't know how portable the interface is beyond that, and lack of portability might prevent upstream from adopting it. It would be interesting to see this as an option for Debian, though. (Does Hurd implement SO_PEERCRED?) Yes; this makes it look possible - I am pretty sure it is not portable, though, so it won't be an upstream option. How portable is it within Linux? I just tried looking for the documentation on it in libc.info and couldn't find anything. -- Oliver Elphick[EMAIL PROTECTED] 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 For whosoever will save his life shall lose it. But whosoever will lose his life for my sake, the same shall save it. Luke 9:24
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Oliver Elphick olly@lfix.co.uk writes: It is indeed the case that ident is needed to allow local access without a password. I understand that this presents a small security risk on the server. I think README.Debian or somesuch should tell why ident is necessary, and perhaps also how one can restrict ident access (e.g. by firewalling port 113 except for localhost). In case anyone should ask why the server cannot authenticate directly, communication between front- and back-ends is done through a Unix socket and therefore it is not possible for the back-end to know the identity of the user at the front-end. That's not true for Linux 2.[24].x at least. One can use getsockopt(..., SO_PEERCRED, ...) to get the uid of the other end. It would be nice if you could request that as an upstream feature. -- Robbe signature.ng Description: PGP signature
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Robert Bihlmeyer wrote: That's not true for Linux 2.[24].x at least. One can use getsockopt(..., SO_PEERCRED, ...) to get the uid of the other end. It would be nice if you could request that as an upstream feature. The upstream developers are not friendly to non-portable features; I might be able to get it added under a config option. (portable means BSD Linux AIX HP-UX VAX Solaris Windows ...) -- Oliver Elphick[EMAIL PROTECTED] 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 For whosoever will save his life shall lose it. But whosoever will lose his life for my sake, the same shall save it. Luke 9:24
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
On Mon, 30 Apr 2001, Oliver Elphick wrote: This works for Unix sockets under Linux 2.2 and Linux 2.4, at least. I don't know how portable the interface is beyond that, and lack of portability might prevent upstream from adopting it. It would be interesting to see this as an option for Debian, though. (Does Hurd implement SO_PEERCRED?) Yes; this makes it look possible - I am pretty sure it is not portable, though, so it won't be an upstream option. How portable is it within Linux? I just tried looking for the documentation on it in libc.info and couldn't find anything. I seem to recall first being tipped off to the existence of this facility in a book on generic SysV programming, but this might just be my memory playing tricks on me. At the very least, it works on all Linux kernels we support in Debian (unstable). An earlier interface I had been using, trying to pop SCM_CREDENTIALS messages off the socket manually, is apparently less portable, as my code started segfaulting when run under 2.4. :) Steve Langasek postmodern programmer
Re: Bug#95818: libpgsql2.1: should not depend on ident-server
Oliver == Oliver Elphick olly@lfix.co.uk writes: Oliver It is indeed the case that ident is needed to allow local Oliver access without a password. I understand that this Oliver presents a small security risk on the server. However, Oliver without it, it is necessary for the postgres Oliver administrator's database password to be held in clear in Oliver some file, so that the automatic clean-up processes will Oliver be able to operate. Could be a disaster on some systems. I think same ident servers, like oidentd, allow individual users to customise their own responses: [...] -s Allow identd reply spoofing. In order for a non- root user to spoof its identd reply, the username must be listed in /etc/identd.spoof. The spoofed reply can optionally be specified in the /etc/identd.spoof file. Forexample,if user:string were an entry in /etc/identd.spoof, any successful lookups for user would result in the reply string being returned. If the reply is not specified in the /etc/identd.spoof file, the spoofed reply will be read from an .ispoof file in the user's home directory. If a user is not allowed to spoof identd replies or there is an error read ing the .ispoof file, if the -r flag has been passed to identd, a randomized identd reply will be returned. If not, the user's username will be returned. Non-root users are allowed to spoof identd replies on ports greater than 1023. Non-root users may spoof identd replies on all ports if the -A option is specified. -S Same as '-s' but allow all users to spoof identd replies except for those users listed in the /etc/identd.spoof file. [...] $HOME/.ispoof File containing username to return when oidentd is run with the -s flag. [note: the above requires careful reading; in order to enable non-root spoofing you have to pass -s *and* put the user in the /etc/identd.spoof file *without* a reply; -S is different] This isn't something I like (read: hate), but I am bringing it up because it could be a serious security hole when used by programs like postgresql. -- Brian May [EMAIL PROTECTED]
