/- On Monday (8/16/2004 19:35) Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dallas N Antley <dna+pgsql@clas.ufl.edu> writes:
> > I think I know why pam authentication fails with the pam_unix*
> > modules, but would appreciate your opinion.
>
> I think you've proven that the particular PAM modules you are testing
> with are useless for programs executing as non-root, but that doesn't
> mean the entire concept is broken. Look around ... there are lots of
> PAM modules (or at least that's the theory).
Correct. I'm only referring to pam_unix* modules. This has come up
on the list a few times, but there's never been a "solution" in any of
the replies.
http://archives.postgresql.org/pgsql-admin/2003-02/msg00301.php
http://archives.postgresql.org/pgsql-admin/2003-01/msg00352.php
http://archives.postgresql.org/pgsql-admin/2002-10/msg00066.php
http://archives.postgresql.org/pgsql-admin/2002-08/msg00281.php
http://archives.postgresql.org/pgsql-admin/2002-06/msg00110.php
http://archives.postgresql.org/pgsql-admin/2002-05/msg00233.php
http://archives.postgresql.org/pgsql-admin/2002-05/msg00075.php
This is why login, dtsession, xscreensaver, etc are setuid under
Solaris, and probably under Linux distributions that use /etc/shadow,
C2-NIS, and/or NIS+. Given the current security model employed by the
postmaster process, this wouldn't be trivial.
Considering the number of times this came up in the archives, and
after getting stuck myself, I'd like to get this added to the FAQ,
assuming I'm correct in my logic.
> BTW, what are those "door_info()" and "door_call()" calls shown in the
> truss output? Could it be that those are supposed to get the PAM code
> into a higher authorization level?
Doors are a Solaris-specific (AFAIK) type of inter-process
communication -- similar to sockets, but faster. They're used inside
the PAM libraries for name service, syslog calls, etc.
Dallas
