Thread: su not working with psql
I'm new to this list and new to PostgreSQL, so I hope this question isn't off-base. I'm running version 8.2 in Mac OS X 10.5.8. I installed it in a new "postgres" user account. I can access it via PGAdmin and via a test application I'm writing, both from my normal user account, "david". I can also access it in the Terminal using psql when logged into the postgres user account. But when I'm logged into my "david" account and try to access the database via sql I get the following: imac:~ david$ su - postgres Password: imac:~ postgres$ psql fcddb psql: FATAL: role "david" does not exist imac:~ postgres$ whoami postgres I wonder if anybody has any idea what's going wrong? The system appears to correctly see me as postgres after using the su command, as evidenced by the response to whoami. But somehow the PostgreSQL process or psql is seeing me as "david". I have tested to see if creating a role for david in the database solves this problem, and it does. But I'm concerned that there's something fundamentally wrong here that needs to be addressed.
The PandaWare Company <lists@pandaware.com> writes:
> I'm running version 8.2 in Mac OS X 10.5.8. I installed it in a new
> "postgres" user account. I can access it via PGAdmin and via a test
> application I'm writing, both from my normal user account, "david". I
> can also access it in the Terminal using psql when logged into the
> postgres user account. But when I'm logged into my "david" account and
> try to access the database via sql I get the following:
> imac:~ david$ su - postgres
> Password:
> imac:~ postgres$ psql fcddb
> psql: FATAL: role "david" does not exist
> imac:~ postgres$ whoami
> postgres
Huh. Do you have Kerberos credentials by any chance? I'm not sure
if "su" would affect that.
regards, tom lane
On Aug 18, 2009, at 12:00 PM, Tom Lane wrote: > The PandaWare Company <lists@pandaware.com> writes: >> I'm running version 8.2 in Mac OS X 10.5.8. I installed it in a new >> "postgres" user account. I can access it via PGAdmin and via a test >> application I'm writing, both from my normal user account, "david". I >> can also access it in the Terminal using psql when logged into the >> postgres user account. But when I'm logged into my "david" account >> and >> try to access the database via sql I get the following: > >> imac:~ david$ su - postgres >> Password: >> imac:~ postgres$ psql fcddb >> psql: FATAL: role "david" does not exist >> imac:~ postgres$ whoami >> postgres > > Huh. Do you have Kerberos credentials by any chance? I'm not sure > if "su" would affect that. Not that I'm aware of.
On Aug 18, 2009, at 1:35 PM, Michael Wood wrote: > Do you by any chance have the PGUSER environment variable set to > "david"? > > e.g.: > imac:~ postgres$ echo $PGUSER > > or: > imac:~ postgres$ env | grep david Both commands return an empty string. Does this mean that I need to set the PGUSER environment variable? If so, how do I do that?
The PandaWare Company <lists@pandaware.com> writes:
> On Aug 18, 2009, at 12:00 PM, Tom Lane wrote:
>> Huh. Do you have Kerberos credentials by any chance? I'm not sure
>> if "su" would affect that.
> Not that I'm aware of.
I doubt you could have it running and not be aware of it ;-)
Eliminating Kerberos, there's no obvious reason for this --- libpq
looks at geteuid() as far as I can see. What does your pg_hba.conf
setup look like?
regards, tom lane
On Aug 18, 2009, at 1:56 PM, Tom Lane wrote: > The PandaWare Company <lists@pandaware.com> writes: >> On Aug 18, 2009, at 12:00 PM, Tom Lane wrote: >>> Huh. Do you have Kerberos credentials by any chance? I'm not sure >>> if "su" would affect that. > >> Not that I'm aware of. > > I doubt you could have it running and not be aware of it ;-) > > Eliminating Kerberos, there's no obvious reason for this --- libpq > looks at geteuid() as far as I can see. What does your pg_hba.conf > setup look like? The only thing I added to the default file was a line to permit IPv4 connections from hosts on my LAN.
The PandaWare Company <lists@pandaware.com> writes:
> On Aug 18, 2009, at 1:56 PM, Tom Lane wrote:
>> Eliminating Kerberos, there's no obvious reason for this --- libpq
>> looks at geteuid() as far as I can see. What does your pg_hba.conf
>> setup look like?
> The only thing I added to the default file was a line to permit IPv4
> connections from hosts on my LAN.
Please show us the actual file, rather than suppressing details that you
think are irrelevant.
(In this particular instance, the reason your answer is unhelpful is
that the default file contents are variable.)
regards, tom lane
On Aug 18, 2009, at 2:30 PM, Tom Lane wrote: > The PandaWare Company <lists@pandaware.com> writes: >> The only thing I added to the default file was a line to permit IPv4 >> connections from hosts on my LAN. > > Please show us the actual file, rather than suppressing details that > you > think are irrelevant. > > (In this particular instance, the reason your answer is unhelpful is > that the default file contents are variable.) I didn't realize that. Here are the entire file contents: # PostgreSQL Client Authentication Configuration File # =================================================== # # Refer to the "Client Authentication" section in the # PostgreSQL documentation for a complete description # of this file. A short synopsis follows. # # This file controls: which hosts are allowed to connect, how clients # are authenticated, which PostgreSQL user names they can use, which # databases they can access. Records take one of these forms: # # local DATABASE USER METHOD [OPTION] # host DATABASE USER CIDR-ADDRESS METHOD [OPTION] # hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION] # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION] # # (The uppercase items must be replaced by actual values.) # # The first field is the connection type: "local" is a Unix-domain socket, # "host" is either a plain or SSL-encrypted TCP/IP socket, "hostssl" is an # SSL-encrypted TCP/IP socket, and "hostnossl" is a plain TCP/IP socket. # # DATABASE can be "all", "sameuser", "samerole", a database name, or # a comma-separated list thereof. # # USER can be "all", a user name, a group name prefixed with "+", or # a comma-separated list thereof. In both the DATABASE and USER fields # you can also write a file name prefixed with "@" to include names from # a separate file. # # CIDR-ADDRESS specifies the set of hosts the record matches. # It is made up of an IP address and a CIDR mask that is an integer # (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies # the number of significant bits in the mask. Alternatively, you can write # an IP address and netmask in separate columns to specify the set of hosts. # # METHOD can be "trust", "reject", "md5", "crypt", "password", # "krb5", "ident", "pam" or "ldap". Note that "password" sends passwords # in clear text; "md5" is preferred since it sends encrypted passwords. # # OPTION is the ident map or the name of the PAM service, depending on METHOD. # # Database and user names containing spaces, commas, quotes and other special # characters must be quoted. Quoting one of the keywords "all", "sameuser" or # "samerole" makes the name lose its special character, and just match a # database or username with that name. # # This file is read on server startup and when the postmaster receives # a SIGHUP signal. If you edit the file on a running system, you have # to SIGHUP the postmaster for the changes to take effect. You can use # "pg_ctl reload" to do that. # Put your actual configuration here # ---------------------------------- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL listen # on a non-local interface via the listen_addresses configuration parameter, # or via the -i or -h command line switches. # # CAUTION: Configuring the system for local "trust" authentication allows # any local user to connect as any PostgreSQL user, including the database # superuser. If you do not trust all your local users, use another # authentication method. # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust host all all 10.0.0.0/24 trust # IPv6 local connections: host all all ::1/128 trust
The PandaWare Company <lists@pandaware.com> writes:
> local all all trust
OK, that eliminates another possibility (that ident was doing something
weird).
I just thought of another theory, though --- maybe you have a ~/.pgpass
file that's selecting userid david? Unless "su" is behaving differently
than it seems to here, that would be in postgres' home directory not
david's, but you might have copied david's file ...
regards, tom lane
On Aug 18, 2009, at 2:57 PM, Tom Lane wrote: > I just thought of another theory, though --- maybe you have a > ~/.pgpass > file that's selecting userid david? Unless "su" is behaving > differently > than it seems to here, that would be in postgres' home directory not > david's, but you might have copied david's file ... Using the "locate" command in Terminal, the only one I see is in david's home directory. It has an entry for a remote server, in connection with a project I worked on briefly some months ago.
On Aug 18, 2009, at 3:17 PM, The PandaWare Company wrote: > On Aug 18, 2009, at 2:57 PM, Tom Lane wrote: > >> I just thought of another theory, though --- maybe you have a >> ~/.pgpass >> file that's selecting userid david? Unless "su" is behaving >> differently >> than it seems to here, that would be in postgres' home directory not >> david's, but you might have copied david's file ... > > Using the "locate" command in Terminal, the only one I see is in > david's home directory. It has an entry for a remote server, in > connection with a project I worked on briefly some months ago. Correction: I forgot to mention that the listing for the old project does not even have "david" in its content. And, there is also a listing for a connection to localhost, but it too lacks any mention of "david".
The PandaWare Company <lists@pandaware.com> writes:
>> Using the "locate" command in Terminal, the only one I see is in
>> david's home directory.
Are you sure "locate" would search postgres' home directory?
The man page suggests it will only find publicly readable files,
which .pgpass wouldn't be even if ~postgres is.
regards, tom lane
The PandaWare Company <lists@pandaware.com> writes:
> But this problem is now solved!
> I restarted my Mac, launched Terminal, su'ed to postgres and
> successfully got into the database.
> Now I guess I have to wonder what was causing the problem before the
> relaunch.
[ scratches head... ] I'm confused too.
regards, tom lane
The PandaWare Company wrote:
> On Aug 18, 2009, at 2:57 PM, Tom Lane wrote:
>
>> I just thought of another theory, though --- maybe you have a ~/.pgpass
>> file that's selecting userid david? Unless "su" is behaving differently
>> than it seems to here, that would be in postgres' home directory not
>> david's, but you might have copied david's file ...
>
> Using the "locate" command in Terminal, the only one I see is in david's
> home directory. It has an entry for a remote server, in connection with
> a project I worked on briefly some months ago.
>
locate does not include recently created files.
What is the output of:
su - postgres
whoami
ls -l ~/.pgpass
cat ~/.pgpass
On Aug 18, 2009, at 3:24 PM, Tom Lane wrote: > The PandaWare Company <lists@pandaware.com> writes: >>> Using the "locate" command in Terminal, the only one I see is in >>> david's home directory. > > Are you sure "locate" would search postgres' home directory? > The man page suggests it will only find publicly readable files, > which .pgpass wouldn't be even if ~postgres is. I was su'ed in as postgres at the time (when it showed me the file in david's home directory). But this problem is now solved! I restarted my Mac, launched Terminal, su'ed to postgres and successfully got into the database. Now I guess I have to wonder what was causing the problem before the relaunch. Thanks for all the help to try to figure this out. As I said originally, I'm new to PostgreSQL. I learned a few things in this exchange.
On Aug 18, 2009, at 3:41 PM, Frank Bax wrote: > The PandaWare Company wrote: >> On Aug 18, 2009, at 2:57 PM, Tom Lane wrote: >>> I just thought of another theory, though --- maybe you have a >>> ~/.pgpass >>> file that's selecting userid david? Unless "su" is behaving >>> differently >>> than it seems to here, that would be in postgres' home directory not >>> david's, but you might have copied david's file ... >> Using the "locate" command in Terminal, the only one I see is in >> david's home directory. It has an entry for a remote server, in >> connection with a project I worked on briefly some months ago. > > > locate does not include recently created files. > > What is the output of: > su - postgres > whoami > ls -l ~/.pgpass > cat ~/.pgpass As I mentioned earlier, after the su - postgres command, whoami returned "postgres". ls -l ~/.pgpass returns: ls: /Users/postgres/.pgpass: No such file or directory
I've had su behave in strange ways if the numeric UID was not set the same on all systems. We use Solaris so I don't know if this problem would exist in other systems. We also use ldap. What happens is that postgres comes bundled with Solaris. We use ldap so we have a systemwide postgres user. The Solaris install also creates a local postgres user. Since the system reads the local password file first, that's the user that it gets. Going across systems causes real problems, if you don't correct the discrepancy. Carol On Aug 18, 2009, at 5:57 PM, Tom Lane wrote: > The PandaWare Company <lists@pandaware.com> writes: >> local all all trust > > OK, that eliminates another possibility (that ident was doing > something > weird). > > I just thought of another theory, though --- maybe you have a > ~/.pgpass > file that's selecting userid david? Unless "su" is behaving > differently > than it seems to here, that would be in postgres' home directory not > david's, but you might have copied david's file ... > > regards, tom lane > > -- > Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-novice