openssh unix dev - Oct 2001 - 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]: Permission denied

The 2 errors:

pam_setcred: error Permission denied
Cannot delete credentials[7]: Permission denied

Looks to be a major bug in the PAM module for Solaris-2.8/2.7/2.6.
Has anyone from the list (developers of OpenSSH, endusers, hackers, etc.)
came up w/ a solution? Even a temporary one?
When authenticating yourself on the same system that worked, but when
authenticating to another system failed.  I even tried to placed entries
within /etc/pam.conf w/ no success.  If there's no viable solution (even
with
key authentication) then I'll have to revert back to SSH-3.0.1/SSH-1.2.31.

Thanks.

- Wally Winzer Jr.

P.S. Pls send all replies to wally.winzer at ChampUSA.COM for I don't
belong to this list as of yet.  Thx.

On Wed, 31 Oct 2001, Auteria Wally Winzer Jr. wrote:
> The 2 errors:
> 
> pam_setcred: error Permission denied
> Cannot delete credentials[7]: Permission denied
This hasn't caused visible problems in the past - what are you seeing?

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at
mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)

On Wed, 31 Oct 2001, Auteria Wally Winzer Jr. wrote:
> Date: Wed, 31 Oct 2001 15:01:14 -0800
> From: Auteria Wally Winzer Jr. <wally.winzer at ChampUSA.COM>
> To: openssh-unix-dev at mindrot.org
> Subject: 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]:
>     Permission  denied
>
> The 2 errors:
>
> pam_setcred: error Permission denied
> Cannot delete credentials[7]: Permission denied
>
> Looks to be a major bug in the PAM module for Solaris-2.8/2.7/2.6.
> Has anyone from the list (developers of OpenSSH, endusers, hackers, etc.)
> came up w/ a solution? Even a temporary one?
> When authenticating yourself on the same system that worked, but when
> authenticating to another system failed.  I even tried to placed entries
> within /etc/pam.conf w/ no success.  If there's no viable solution
(even with
> key authentication) then I'll have to revert back to
SSH-3.0.1/SSH-1.2.31.
I reported this problem recently too... the result is that "keylogout"
(destroy Secure RPC credentials) is not run for the user when the user
logs out.  Other than that, it really has no impact except for the error
message (if you have logging turned up to that level).

The only solution I see (in lieu of Sun fixing it - which is what people
on the list have suggested is the "right thing") - is to change
do_pam_cleanup_proc() in auth-pam.c to do a seteuid() with the user's uid
before calling pam_setcred(), and then, I guess, call seteuid(0)
afterwards to make the rest of the cleanup code run as uid 0 like it used
to.  This should at least get keylogout to work for the user.

Darren, can you tell us why Sun decided to implement
pam_sm_setcred(PAM_DELETE_CRED) the way they did in pam_unix.so?
Shouldn't keylogout be run for PAM_USER and not the euid of the caller?

Hope this helps!

	Ed

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key

>Darren, can you tell us why Sun decided to implement
>pam_sm_setcred(PAM_DELETE_CRED) the way they did in pam_unix.so?
>Shouldn't keylogout be run for PAM_USER and not the euid of the caller?
This was because of a limitation in the internal API between libnsl and
keyserv at the time pam_unix was written, this limitation has only
recenly gone away.

This will probably be fixed in the next release of Solaris but it is
not easy for us to backport it as a patch at this time (due to the nature
of the changes).

--
Darren J Moffat