From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David M(dot) Kaplan" <dkaplan(at)bio(dot)puc(dot)cl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: local security |
Date: | 2001-04-17 14:06:04 |
Message-ID: | 23385.987516364@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"David M. Kaplan" <dkaplan(at)bio(dot)puc(dot)cl> writes:
> Even better would be that postgres uses the standard unix security
> and that on connecting it asks for the appropriate unix password unless you
> are a superuser in which case it just connects.
This would tie Postgres usernames to usernames of the surrounding
system, which is something that we've explicitly avoided doing.
There are many scenarios where you don't want to have to grant every
database user a shell account on the database host machine.
Another serious problem is how do you know what Unix userid is at the
other end of the connection? If it's a localhost TCP connection then
maybe you can trust IDENT protocol to find out, but AFAIK there's no
portable equivalent for Unix-socket connections.
Finally, I don't much care for the assumption that superuserness on the
Unix side should automatically translate to superuserness in Postgres
land. We've worked hard to ensure that routine Postgres administration
does not require system root privileges, and I don't think that the
access-control scheme should encourage people to break that
compartmentalization. If you're doing Postgres-related work as root,
you're too likely to slip up and give something root privs that
shouldn't have 'em.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-04-17 14:16:14 | Re: local security |
Previous Message | Peter T Mount | 2001-04-17 13:59:16 | Re: Oracle to PostgreSQL |