On Sat, Apr 9, 2011 at 19:29, Joshua Berkus wrote:
> All,
>
> We left this out of 9.0; let's not leave it out of 9.1. We need an example
> "replication" line in pg_hba.conf, commented out. e.g.
>
> # host replication all samenet md5
>
> Also, what happened to having a "replication" us
On tor, 2010-10-21 at 06:38 +0300, Peter Eisentraut wrote:
> So, as previously indicated, let's add some wildcard support to the
> pg_hba.conf host name feature. After looking around a bit, two syntaxes
> appear to be on offer:
>
> 1. TCP Wrappers style, leading dot indicates suffix match.
> So .
Tom Lane writes:
> Peter Eisentraut writes:
>> 1. TCP Wrappers style, leading dot indicates suffix match.
>> So .example.com matches anything.example.com. Not sure how useful that
>> would be, but it could be implemented in about 3 lines of code.
>
> I'd lean to #1 myself.
FWIW, +1
--
Dimitri
Peter Eisentraut writes:
> So, as previously indicated, let's add some wildcard support to the
> pg_hba.conf host name feature. After looking around a bit, two syntaxes
> appear to be on offer:
> 1. TCP Wrappers style, leading dot indicates suffix match.
> So .example.com matches anything.exampl
Stef Walter writes:
> [ postgres-hba-samenet-8.patch ]
Applied with some mostly-cosmetic editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
At 2009-09-30 11:16:57 -0500, stef-l...@memberwebs.com wrote:
>
> I've now added tests for sys/ioctl.h and net/if.h even though these
> headers seemed to be common to all the unixes investigated.
Thanks. I've marked this ready for committer now.
> FWIW, there are checks for various bad netmasks.
Tom Lane wrote:
> I was just poking at this.
Thanks for trying it out.
It seems to need rather a lot of
> editorialization (eg to fix the lack of consistency about whether
> nonstandard headers have configure tests, or bother to make use of the
> tests that did get added).
I've now added tes
Robert Haas writes:
> On Mon, Sep 28, 2009 at 4:04 PM, Stef Walter wrote:
>> * Tested on Solaris, FreeBSD, Linux and Windows. As far as I can tell
>> this should also work on Mac OS, HPUX and AIX, and probably others.
> This look ready to you, too? If so, please mark it as such.
I was just
On Mon, Sep 28, 2009 at 4:04 PM, Stef Walter wrote:
> Robert Haas wrote:
>> So is this one Ready for Committer?
>
> Here we go, I think this one is ready. In addition to previous patches,
> it does:
>
> * Use some techniques from postfix for getting interface addresses.
> Couldn't use code outr
Dave Page wrote:
> On Mon, Sep 28, 2009 at 10:10 PM, Stef Walter
> wrote:
>
>> * Win32 using win_wsa2.dll
>
> I assume you mean ws2_32.dll?
Yes. I get dyslexic around windows DLLs. :)
Stef
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Mon, Sep 28, 2009 at 10:10 PM, Stef Walter wrote:
> * Win32 using win_wsa2.dll
I assume you mean ws2_32.dll?
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Whoops I missed this email...
Robert Haas wrote:
> Rereading the thread, it seems that the main question is whether there
> are any platforms that we support that have neither getifaddrs or
> SIOCGIFCONF, or where they don't work properly.
As far as I can tell, there are no non-ancient mainstream
Robert Haas wrote:
> So is this one Ready for Committer?
Here we go, I think this one is ready. In addition to previous patches,
it does:
* Use some techniques from postfix for getting interface addresses.
Couldn't use code outright, due to license incompatibilities.
* Tested on Solaris, Fre
Robert Haas wrote:
>> Attached patch contains a fix.
>
> So is this one Ready for Committer?
Not yet. Two more things to do. Will work on them early next week:
* On Solaris the ioctl used only returns IPv4 addresses.
* Don't use hard coded buffers on win32 and ioctl.
Cheers,
Stef
--
Sen
On Thu, Sep 24, 2009 at 8:32 PM, Stef Walter wrote:
> Magnus Hagander wrote:
>> On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
>> This patch does not build on Windows, the error is:
>> ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36
>> referenced
>> in function _pg_fore
Magnus Hagander wrote:
> On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
> This patch does not build on Windows, the error is:
> ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36
> referenced
> in function _pg_foreach_ifaddr
> ip.obj : error LNK2019: unresolved external sym
On Wed, Sep 23, 2009 at 7:56 PM, Stef Walter wrote:
> Tom Lane wrote:
>> Stef Walter writes:
>>> Allowing host names in pg_hba.conf would also solve this problem,
>>> although the last person who tried to implement this it was a topic of
>>> contention. I asked if I should focus on reverse DNS ho
Stef Walter writes:
> But if you like I can add additional defensive checks in the code to
> ignore those obviously invalid netmasks like /0. Basically the OS would
> be giving postgres bad information. Does postgres generally try to guard
> against this? I'll follow the convention of the project.
Tom Lane wrote:
> Stef Walter writes:
>> Allowing host names in pg_hba.conf would also solve this problem,
>> although the last person who tried to implement this it was a topic of
>> contention. I asked if I should focus on reverse DNS host names in
>> pg_hba.conf or portability for this samenet
Tom Lane wrote:
> Mark Mielke writes:
>> Postfix has this capability and it works fine.
>
> Hmm, have we looked at the Postfix code to see exactly how they do it?
> I'd be a *lot* more comfortable adopting logic that's been proven in the
> field than something written from scratch.
Good idea.
A
On 09/23/2009 05:40 PM, Tom Lane wrote:
I haven't looked at this "feature" at all, but I'd be inclined, on the
grounds you quite reasonably cite, to require a netmask with "samenet",
rather than just ask the interface for its netmask.
I was just thinking the same thing. Could we then unif
Mark Mielke writes:
> Postfix has this capability and it works fine.
Hmm, have we looked at the Postfix code to see exactly how they do it?
I'd be a *lot* more comfortable adopting logic that's been proven in the
field than something written from scratch.
regards, tom lan
On 09/23/2009 05:37 PM, Andrew Dunstan wrote:
Tom Lane wrote:
In this case what particularly scares me is the idea that 'samenet'
might be interpreted to let in a larger subnet than the user expected,
eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
after you'd been broke
Andrew Dunstan writes:
> Tom Lane wrote:
>> In this case what particularly scares me is the idea that 'samenet'
>> might be interpreted to let in a larger subnet than the user expected,
>> eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
>> after you'd been broken into ...
Tom Lane wrote:
In this case what particularly scares me is the idea that 'samenet'
might be interpreted to let in a larger subnet than the user expected,
eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
after you'd been broken into ...
I haven't looked at this "fe
If looking for representation -
I consider the default pg_hba.conf to be problematic. Newbies start with
"trust" access, and then do silly things to open it up.
I would use samehost, and if samenet worked the same way it does for
Postfix, I would probably use samenet. This information can be
Stef Walter writes:
> Allowing host names in pg_hba.conf would also solve this problem,
> although the last person who tried to implement this it was a topic of
> contention. I asked if I should focus on reverse DNS host names in
> pg_hba.conf or portability for this samenet patch, and it was indi
On Wed, Sep 23, 2009 at 3:53 PM, Stef Walter wrote:
> Robert Haas wrote:
>> On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter
>> wrote:
>>> Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
>>> order to allow access from nearby machines, without running into the
>>> maintenance pr
Robert Haas wrote:
> On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter
> wrote:
>> Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
>> order to allow access from nearby machines, without running into the
>> maintenance problems of hard coding IP addresses. However using 0.0.0.0
>>
On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter wrote:
> Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
> order to allow access from nearby machines, without running into the
> maintenance problems of hard coding IP addresses. However using 0.0.0.0
> is clearly suboptimal from
On Wed, Sep 23, 2009 at 18:41, Stef Walter wrote:
> Magnus Hagander wrote:
>> On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
>>
>>
>>
>>> Updated in attached patch.
>>
>> This patch does not build on Windows, the error is:
>> ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@
Magnus Hagander wrote:
> On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
>
>
>
>> Updated in attached patch.
>
> This patch does not build on Windows, the error is:
> ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36
> referenced
> in function _pg_foreach_ifaddr
> ip.ob
On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
> Updated in attached patch.
This patch does not build on Windows, the error is:
ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36 referenced
in function _pg_foreach_ifaddr
ip.obj : error LNK2019: unresolved external symbol
Thanks for your review!
Abhijit Menon-Sen wrote:
> First, it needs to be reformatted to not use a space before the opening
> parentheses in (some) function calls and definitions.
Fixed in the attached patch.
>> *** a/doc/src/sgml/client-auth.sgml
>> --- b/doc/src/sgml/client-auth.sgml
>> [...]
>
On Sun, Sep 20, 2009 at 05:59, Abhijit Menon-Sen wrote:
> I think the patch is more or less ready, but I have a few minor
> comments:
>
> First, it needs to be reformatted to not use a space before the opening
> parentheses in (some) function calls and definitions.
>
>> *** a/doc/src/sgml/client-a
(This is my review of the latest version of Stef Walter's samehost/net
patch, posted on 2009-09-17. See
http://archives.postgresql.org/message-id/4ab28043.3050...@memberwebs.com
for the original message.)
The patch applies and builds cleanly, and the samehost/samenet keywords
in pg_hba.conf work a
[Thanks for the heads up about the MessageID missing when posting this
previously. Was doing some mail filter development, and accidentally
left it in place... ]
Magnus Hagander wrote:
> 2009/8/25 Alvaro Herrera :
>> Something to keep in mind -- my getifaddrs(3) manpage says that on BSD
>> it can
Stef Walter wrote:
> [Looks like my response to this never made it to the mailing list,
> sending again...]
Your original message did not carry a Message-Id header, and neither
does this one (at least the copy I got). Are you doing something weird
to the message? This worries me, because we inte
2009/8/25 Alvaro Herrera :
> Stef Walter wrote:
>> Magnus Hagander wrote:
>
>> > and not just use SIOCGIFCONF for all Unixen?
>>
>> I do know that using SIOCGIFCONF on AIX comes with strange wrinkles and
>> variable length data structures etc... getifaddrs() on AIX is a far more
>> maintainable int
Something is very wrong here -- this message does not have a
message-id!
Stef Walter wrote:
> Magnus Hagander wrote:
> > On Wed, Aug 19, 2009 at 15:02, Stef Walter wrote:
> >> Magnus Hagander wrote:
> >>> On Wed, Aug 19, 2009 at 03:58, Stef Walter
> >>> wrote:
> Attached is a new patch, whi
Stef Walter wrote:
> Magnus Hagander wrote:
> > and not just use SIOCGIFCONF for all Unixen?
>
> I do know that using SIOCGIFCONF on AIX comes with strange wrinkles and
> variable length data structures etc... getifaddrs() on AIX is a far more
> maintainable interface.
Clearly the getifaddrs cod
Magnus Hagander wrote:
> On Wed, Aug 19, 2009 at 15:02, Stef Walter wrote:
>> Magnus Hagander wrote:
>>> On Wed, Aug 19, 2009 at 03:58, Stef Walter wrote:
Attached is a new patch, which I hope addresses all the concerns raised.
>>> I think you forgot to actually attach the patch
>> Whoops.
On Wed, Aug 19, 2009 at 15:02, Stef Walter wrote:
> Magnus Hagander wrote:
>> On Wed, Aug 19, 2009 at 03:58, Stef Walter wrote:
>>> Attached is a new patch, which I hope addresses all the concerns raised.
>>
>> I think you forgot to actually attach the patch
>
> Whoops. Here it is.
Is there an
Magnus Hagander wrote:
> On Wed, Aug 19, 2009 at 03:58, Stef Walter wrote:
>> Attached is a new patch, which I hope addresses all the concerns raised.
>
> I think you forgot to actually attach the patch
Whoops. Here it is.
Stef
diff --git a/configure.in b/configure.in
index 505644a..bc37b1b
On Wed, Aug 19, 2009 at 03:58, Stef Walter wrote:
> Attached is a new patch, which I hope addresses all the concerns raised.
I think you forgot to actually attach the patch
(others have taken care of the question about login already I see)
--
Magnus Hagander
Me: http://www.hagander.net/
On Tue, Aug 18, 2009 at 10:11 PM, Tom Lane wrote:
> Stef Walter writes:
>> Magnus Hagander wrote:
>>> Please add it to the open commitfest
>>> (https://commitfest.postgresql.org/action/commitfest_view/open). This
>>> will cause it to be reviewed during the next commitfest, and then you
>>> just ne
Stef Walter writes:
> Magnus Hagander wrote:
>> Please add it to the open commitfest
>> (https://commitfest.postgresql.org/action/commitfest_view/open). This
>> will cause it to be reviewed during the next commitfest, and then you
>> just need to be around to answer any questions that reviewers co
Attached is a new patch, which I hope addresses all the concerns raised.
Magnus Hagander wrote:
>> I've attached an initial patch which implements "samehost" and
>> "samenet". The patch looks more invasive than it really is, due to
>> necessary indentation change (ie: a if block), and moving some
Stef Walter writes:
> True. I could build compatibility getifaddrs for various systems, if the
> community thought this patch was worth it, and would otherwise accept
> the patch.
If you can do that I think it'd remove the major objection.
regards, tom lane
--
Sent via
Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Aug 14, 2009 at 00:50, Stef Walter wrote:
>>> It would be great if, in the cidr-address field of pg_hba.conf, we could
>>> specify "samehost" and "samenet".
>
>> Seems like a reasonable feature - especially the samehost part.
>
> ISTM people h
Magnus Hagander wrote:
>
> A couple of comments on the patch:
Thanks I'll keep these in mind, as things progress and for future patches.
> * In general, don't include configure in the patch. Just configure.in.
> Makes it easier to read, and configure is normally built by the
> committer anyway.
Magnus Hagander writes:
> On Fri, Aug 14, 2009 at 00:50, Stef Walter wrote:
>> It would be great if, in the cidr-address field of pg_hba.conf, we could
>> specify "samehost" and "samenet".
> Seems like a reasonable feature - especially the samehost part.
ISTM people have traditionally used 127.0
On Fri, Aug 14, 2009 at 00:50, Stef Walter wrote:
> I love using postgresql, and have for a long time. I'm involved with
> almost a hundred postgresql installs. But this is the first time I've
> gotten into the code.
>
> Renumbering networks happens often, and will happen more frequently as
> IPv4
Magnus Hagander wrote:
Applied.
//Magnus
Thanks.
And thanks, Tom, for pointing out my multiple attempts to free.
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> It sure looks like that's going to try to free new_parsed_lines more
>>> than once. Shouldn't clean_hba_list be done just once?
>
>> Yeah, it should be done in the if branch down below. And I think by our
>> coding standards (or at
Magnus Hagander writes:
> Tom Lane wrote:
>> It sure looks like that's going to try to free new_parsed_lines more
>> than once. Shouldn't clean_hba_list be done just once?
> Yeah, it should be done in the if branch down below. And I think by our
> coding standards (or at least by our conventions
Tom Lane wrote:
> Selena Deckelmann writes:
>> Currently, load_hba() bails on the first parsing error. It would be
>> better for the typo-prone sysadmin if it reported ALL errors, and THEN
>> bailed out.
>
>> This patch implements that behavior. Tested against 8.4 HEAD this morning.
>
> It su
Selena Deckelmann writes:
> Currently, load_hba() bails on the first parsing error. It would be
> better for the typo-prone sysadmin if it reported ALL errors, and THEN
> bailed out.
> This patch implements that behavior. Tested against 8.4 HEAD this morning.
It sure looks like that's going t
Stephen Frost <[EMAIL PROTECTED]> writes:
> While a wildcard does make sense (ie: www*.postgresql.org), I would
> generally expect 'commandprompt.com' to mean '*.commandprompt.com'
> implicitly.
No, that would be a really bad idea. It's not unlikely that
commandprompt.com refers to a specific hos
Stephen Frost wrote:
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
Before we rehearse the discussion we had in June again, please review
it. It ended on these sensible words from Tom at
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00550.php :
I'd have to disagree with this se
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> Before we rehearse the discussion we had in June again, please review
> it. It ended on these sensible words from Tom at
> http://archives.postgresql.org/pgsql-hackers/2006-02/msg00550.php :
I'd have to disagree with this sentiment and agree with Gre
Joshua D. Drake wrote:
Hello,
Per the TODO list:
Allow pg_hba.conf to specify host names along with IP addresses
Host name lookup could occur when the postmaster reads the pg_hba.conf
file, or when the backend starts. Another solution would be to reverse
lookup the connection IP and check th
On Wed, 2006-12-27 at 17:02 -0500, Stephen Frost wrote:
> * Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> > On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
> > > I'm inclined towards doing the reverse-DNS of the connecting IP and then
> > > checking that the forward of that matches.
> >
> >
On Dec 27, 2006, at 1:47 PM, Joshua D. Drake wrote:
On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Allow pg_hba.conf to specify host names along with IP addresses
Excellent.
Host name lookup could occur when the postmaster reads the
p
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
> > I'm inclined towards doing the reverse-DNS of the connecting IP and then
> > checking that the forward of that matches.
>
> Hmm what if it doesn't? Which is the case any many scenario. My tho
>>> Host name lookup could occur when the postmaster reads the pg_hba.conf
>>> file, or when the backend starts. Another solution would be to reverse
>>> lookup the connection IP and check that hostname against the host names
>>> in pg_hba.conf. We could also then check that the host name maps to t
On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
> * Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> > Allow pg_hba.conf to specify host names along with IP addresses
>
> Excellent.
>
> > Host name lookup could occur when the postmaster reads the pg_hba.conf
> > file, or when the backend sta
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> Allow pg_hba.conf to specify host names along with IP addresses
Excellent.
> Host name lookup could occur when the postmaster reads the pg_hba.conf
> file, or when the backend starts. Another solution would be to reverse
> lookup the connection IP a
how? is there some kernel patch to completely to enable you to deny
access to root?
Tino Wildenhain pointed out SELinux has a feature like that.
I still dont get your problem (apart from that you can always
google for SELinux)
Why arent the other "admins" not trustworthy? And why do you
have ma
Q Beukes schrieb:
how? is there some kernel patch to completely to enable you to deny
access to root?
Tino Wildenhain pointed out SELinux has a feature like that.
I still dont get your problem (apart from that you can always
google for SELinux)
Why arent the other "admins" not trustworthy? And
how? is there some kernel patch to completely to enable you to deny
access to root?
Tino Wildenhain pointed out SELinux has a feature like that.
Rick Gigger wrote:
> But why do they need access to the files in the file system? Why not
> put them on the local box but don't give them permissions
But why do they need access to the files in the file system? Why not
put them on the local box but don't give them permissions to edit the
pg_hba file? They should still be able to connect.
On Feb 9, 2006, at 5:56 PM, Q Beukes wrote:
I did consider that, but the software we use (which agai
I did consider that, but the software we use (which again uses postgresql)
atm only supports local connection to the database.
I am the database admin, the other admins just manage stuff like user
accounts,
checking logs, etc...
Unfortunately there is no other way to set it up, and like I mention
> Why would you not simply set this up on a seperate machine to which only
> the trusted admins had access? Most data centers I am familiar with use
> single purpose machines anyway. If someone is trusted as root on your
> box they can screw you no matter what you do. Pretending otherwise is
> just
korry wrote:
I was suggesting that pg_hba.conf could be stored in the same encrypting
filesystem.
Then how can it be changed? What if you need to allow access from, say,
another user or another network? Oh, the admins have to change it ...
Not all admins are equal... the admin tha
> >I was suggesting that pg_hba.conf could be stored in the same encrypting
> >filesystem.
>
> Then how can it be changed? What if you need to allow access from, say,
> another user or another network? Oh, the admins have to change it ...
Not all admins are equal... the admin that takes care of th
korry wrote:
Since what he is worried about is the ability of admins to get at the
data by connecting to the postgres server (after changing pg_hba.conf),
this will not make the slightest difference - the data would be
decrypted before it ever got to the intruder.
I was suggesting that pg
> Since what he is worried about is the ability of admins to get at the
> data by connecting to the postgres server (after changing pg_hba.conf),
> this will not make the slightest difference - the data would be
> decrypted before it ever got to the intruder.
I was suggesting that pg_hba.conf coul
korry wrote:
If you want the data hidden from system administrators, you need to have
the client encrypt it before storing it. Of course, that will have
massive implications for your application.
Have you considered storing your data on an encrypted filesystem? I have no
idea what kind
> If you want the data hidden from system administrators, you need to have
> the client encrypt it before storing it. Of course, that will have
> massive implications for your application.
Have you considered storing your data on an encrypted filesystem? I have no
idea what kind of performance h
To give it to you straight... its just to ease the minds of management.
Someone pointed out to them how easy it really is to access the data, and
this kind of started to make them feel uncomfortable.
They know the admins are very computer literate and that any protection
can be broken by them.
B
Q Beukes schrieb:
Well,
I am not looking for 100% security. I know that full access if full access,
and that even if you were to encrypt the system through Postgre the
determined
person WILL always be able to get it out if they have system level access.
All I wanted to do was to prevent the bas
Q Beukes wrote:
Well,
I am not looking for 100% security. I know that full access if full access,
and that even if you were to encrypt the system through Postgre the
determined
person WILL always be able to get it out if they have system level access.
All I wanted to do was to prevent the basi
Well,
I am not looking for 100% security. I know that full access if full access,
and that even if you were to encrypt the system through Postgre the
determined
person WILL always be able to get it out if they have system level access.
All I wanted to do was to prevent the basic SQL/Linux literat
>
>
> Q Beukes wrote:
>
>>Hello,
>>
>>Is there not some other alternative to pg_hba.conf?
>>
>>I have the problem where the system administrators at our company
>>obviously have access to the whole filesystem, and our database records
>>needs to be hidden even from them.
>>
>>With pg_hba.conf that
Q Beukes wrote:
Hello,
Is there not some other alternative to pg_hba.conf?
I have the problem where the system administrators at our company
obviously have access to the whole filesystem, and our database records
needs to be hidden even from them.
With pg_hba.conf that is not possible, as t
> Hello,
>
> Is there not some other alternative to pg_hba.conf?
>
> I have the problem where the system administrators at our company
> obviously have access to the whole filesystem, and our database records
> needs to be hidden even from them.
If they have full access, then they have FULL access
On Wed, Feb 08, 2006 at 02:34:29PM +0200, Q Beukes wrote:
> Is there not some other alternative to pg_hba.conf?
>
> I have the problem where the system administrators at our company
> obviously have access to the whole filesystem, and our database records
> needs to be hidden even from them.
>
>
I think this was discussed many times on this list, and the main
conclusion was: if you don't trust your DB machine's admin, any security
measure against him will be only illusory. The sysadmin can in any case
access the data, you can just make this harder, you can't prevent that.
So you better ge
Hi,
On Wed, 2006-02-08 at 14:34 +0200, Q Beukes wrote:
> I have the problem where the system administrators at our company
> obviously have access to the whole filesystem, and our database records
> needs to be hidden even from them.
As they have access to whole filesystem, they can access anyth
> -Original Message-
> From: ElayaRaja S [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 18, 2005 1:38 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] pg_hba.conf
>
>
> Hi,
> I am using Redhat linux 9. i had configure in pg_hba.conf as
> hostpostgres postgres 10.10.0.76
Andrew Dunstan wrote:
> Tom Lane said:
> > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >> Since our defaults don't use old-style masks any more, I would be
> >> tempted to remove the column labels for IP-ADDRESS and IP-MASK, and
> >> instead put in a single heading of IP-ADDRESS/CIDR-MASK.
> >
>
Tom Lane said:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Since our defaults don't use old-style masks any more, I would be
>> tempted to remove the column labels for IP-ADDRESS and IP-MASK, and
>> instead put in a single heading of IP-ADDRESS/CIDR-MASK.
>
> I don't know why there is any deb
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Since our defaults don't use old-style masks any more, I would be tempted to
> remove the column labels for IP-ADDRESS and IP-MASK, and instead put in a
> single heading of IP-ADDRESS/CIDR-MASK.
I don't know why there is any debate about this. When I
Bruce Momjian said:
> Joshua D. Drake wrote:
>> Bruce Momjian wrote:
>>
>> >We have an IP-MASK column in pg_hba.conf. Now that we are using CIDR
>> >addresses by default, should we remove the column label?
>> >
>> >
>> >
>> I would mark it optional.
>
> We could do that, but we could use the space
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >We have an IP-MASK column in pg_hba.conf. Now that we are using CIDR
> >addresses by default, should we remove the column label?
> >
> >
> >
> I would mark it optional.
We could do that, but we could use the space if we removed it. One
other
Bruce Momjian wrote:
We have an IP-MASK column in pg_hba.conf. Now that we are using CIDR
addresses by default, should we remove the column label?
I would mark it optional.
We still support the a netmask value if they don't use CIDR format, but
now that the default is CIDR, it seems we should
Bruce Momjian said:
> I didn't like the Solaris bug mention in pg_hba.conf. It seemed like
> the wrong place:
>
> + # Note: On some Solaris systems, an IP-MASK of 255.255.255.255 is
> known not to work. + # The corresponding CIDR-MASK of /32 does work.
>
> I have removed it. Should we put somethi
On Tue, 2004-04-06 at 08:23, Richard Huxton wrote:
> On Tuesday 06 April 2004 12:10, Fabien COELHO wrote:
> >
> > I'm thinking of allowing advices about incoherent or dangerous "host base
> > authentification" configurations. I would like to access pg_hba.conf
> > from within the database. However,
> > - is it a design principle that this information is not available,
> > or just a lack of time and/or need up to know?
> > would it make sense to add such a view?
>
> I believe the thinking is that you want to check whether someone is
> allowed to connect to the database without having to c
1 - 100 of 110 matches
Mail list logo
