Thread: PAM authentication fails for local UNIX users
Hi all, http://archives.postgresql.org/pgsql-admin/2003-02/msg00301.php I also try to address the same issue.. I run postmaster as postgres user and pg_hba.conf includes the following entry: local all dhanaraj pam However, the authentication fails for this unix local user, whereas it works for LDAP users. bash-3.00$ psql -h superdesktop.india.sun.com -U dhanaraj mydb Password for user dhanaraj: psql: FATAL: PAM authentication failed for user "dhanaraj" The following error message that I could see in the server log: ...................... LOG: pam_authenticate failed: Conversation failure FATAL: PAM authentication failed for user "dhanaraj" LOG: pam_authenticate failed: No account present for user FATAL: PAM authentication failed for user "dhanaraj" The non-root user does not have the permission to read other unix local user password. I found two solutions: 1. usermod -K defaultpriv=Basic,file_dac_read postgres - Gives privilege to read all files. This solution works. Is it the right way to do? 2. chmod +s processName - This does not work, because postgres never allows this. Is there anyother solution to this problem? Thanks Dhanaraj
Dhanaraj M wrote: > Hi all, > > http://archives.postgresql.org/pgsql-admin/2003-02/msg00301.php > > I also try to address the same issue.. > > I run postmaster as postgres user and pg_hba.conf includes the > following entry: > > local all dhanaraj pam > > However, the authentication fails for this unix local user, whereas it > works for LDAP users. > > bash-3.00$ psql -h superdesktop.india.sun.com -U dhanaraj mydb > Password for user dhanaraj: > psql: FATAL: PAM authentication failed for user "dhanaraj" > > The following error message that I could see in the server log: > ...................... > LOG: pam_authenticate failed: Conversation failure > FATAL: PAM authentication failed for user "dhanaraj" > LOG: pam_authenticate failed: No account present for user > FATAL: PAM authentication failed for user "dhanaraj" > > > The non-root user does not have the permission to read other unix > local user password. > I found two solutions: > > 1. usermod -K defaultpriv=Basic,file_dac_read postgres > > - Gives privilege to read all files. This solution works. Is it the > right way to do? > > 2. chmod +s processName > > - This does not work, because postgres never allows this. > > > Is there anyother solution to this problem? Usage questions really don't belong on -hackers - in future please use -general. Both your proposed solutions are utterly insecure. See http://itc.musc.edu/wiki/PostgreSQL for some discussion of using PAM for postgres auth. cheers andrew
Andrew Dunstan wrote: > > > Dhanaraj M wrote: >> >> The non-root user does not have the permission to read other unix >> local user password. >> I found two solutions: >> >> 1. usermod -K defaultpriv=Basic,file_dac_read postgres >> >> - Gives privilege to read all files. This solution works. Is it the >> right way to do? >> >> 2. chmod +s processName >> >> - This does not work, because postgres never allows this. >> >> >> Is there anyother solution to this problem? > > Usage questions really don't belong on -hackers - in future please use > -general. Both your proposed solutions are utterly insecure. The problem what Dhanaraj tries to address is how to secure solve problem with PAM and local user. Other servers (e.g. sshd) allow to run master under root (with limited privileges) and forked process under normal user. But postgresql requires start as non-root user. It limits to used common pattern. There is important question: Is current requirement to run postgresql under non-root OK? If yes, than we must update PAM documentation to explain this situation which will never works secure. Or if we say No, it is stupid limitation (in case when UID 0 says nothing about user's privileges) then we must start discussion about solution. > > See http://itc.musc.edu/wiki/PostgreSQL for some discussion of using > PAM for postgres auth. It also offer also same insecure solution to add read permission on shadow for postgresql user. Zdenek
Zdenek Kotala wrote: > > The problem what Dhanaraj tries to address is how to secure solve > problem with PAM and local user. Other servers (e.g. sshd) allow to > run master under root (with limited privileges) and forked process > under normal user. But postgresql > requires start as non-root user. It limits to used common pattern. > > There is important question: > > Is current requirement to run postgresql under non-root OK? If yes, > than we must update PAM documentation to explain this situation which > will never works secure. Or if we say No, it is stupid limitation (in > case when UID 0 says nothing about user's privileges) then we must > start discussion about solution. > > For now I think we should update the docs. You really can't compare postgres with sshd - ssh connections are in effect autonomous. I suspect the changes involved in allowing us to run as root and then give up privileges safely would be huge, and the gain quite small. I'd rather see an HBA fallback mechanism, which I suspect might overcome most of the problems being encountered here. cheers andrew
On Mon, August 20, 2007 19:52, Andrew Dunstan wrote: > I'd rather see an HBA fallback mechanism, which I suspect might overcome > most of the problems being encountered here. I implemented a form of that once, so on local connections you could do ident mapping with fallback to PAM or some other password authentication. That seemed useful, e.g. for granting non-interactive access to a program running under a dedicated user and requiring a password from everyone else. The implementation also allowed for a bit more flexibility in the auth mechanism. The main objections I recall were: 1. The protocol doesn't allow for multiple authentication prompts. My own proposal didn't have that problem since it only introduced an "optional ident" authentication that continued looking for a matching rule if the current user name was not in the given map, but it's a problem for more general approaches. 2. For real, fully generalized fallback, you'd also need to overhaul the HBA config file format completely. 3. It was considered unsafe to add even the most limited of fallback options, because the HBA config is designed to pick just one auth mechanism for any connection attempt, based on only the first three columns of the config file. An admin who didn't understand the new auth mechanism could use it to write an unsafe HBA configuration, provided it also broke the existing "go from specific-permissive to general-restrictive" design guideline. Personally I think it'd take some careful aim to shoot yourself in the foot like that, but IIRC it was enough for an "I don't like it" vote. Jeroen
Andrew Dunstan wrote:
>
>
> Zdenek Kotala wrote:
>>
>> The problem what Dhanaraj tries to address is how to secure solve
>> problem with PAM and local user. Other servers (e.g. sshd) allow to
>> run master under root (with limited privileges) and forked process
>> under normal user. But postgresql
>> requires start as non-root user. It limits to used common pattern.
>>
>> There is important question:
>>
>> Is current requirement to run postgresql under non-root OK? If yes,
>> than we must update PAM documentation to explain this situation which
>> will never works secure. Or if we say No, it is stupid limitation (in
>> case when UID 0 says nothing about user's privileges) then we must
>> start discussion about solution.
>>
>>
>
> For now I think we should update the docs.
I agree.
> I suspect
> the changes involved in allowing us to run as root and then give up
> privileges safely would be huge, and the gain quite small.
The main problem there is that there are a lot of different ways how to
do it and there is not standard. For example on Solaris applications use
RBAC functionality to handle privileges and this is not available on
other platforms and so on...
> I'd rather see an HBA fallback mechanism, which I suspect might overcome
> most of the problems being encountered here.
The question is why don't use fallback functionality guaranteed by PAM
and naming services. It seems that only fallback to or from password
auth makes sense. Other could be handled by PAM/naming.
Zdenek