On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
> > 
> > I did (as admin@REALM user). But we hardcode root/admin@REALM if
> this is
> > administrative change:
> > 
> > ipapwd_chpwop():
> > ...
> >     if (pwdata.changetype == IPA_CHANGETYPE_NORMAL) {
> >         principal = slapi_entry_attr_get_charptr(pwdata.target,
> >
> "krbPrincipalName");
> >     } else {
> >         principal = slapi_ch_smprintf("root/admin@%s",
> krbcfg->realm);
> >     }
> > ...
> > 
> > Maybe the root cause of the crash is that we place there a principal
> > (root/admin@REALM) which does not exist. But this is just a
> speculation.
> ok, the principal is odd, and I guess this should be fixed, but maybe
> Simo knows some more history here. But nevertheless I think it is
> unrelated to the crash, becaus afaik this information is not send to
> the
> client and only used for book-keeing and auditing on the server side.
I don't recall the root/admin story, looks odd to me, but nothing of
this matter to a *client* segfaulting.

Clients do not get access to this data this is purely internal metadata
used by kadmin and the KDC.

What I wonder is if the client is segfaulting when the password is
expired due to a bug in handling the request to immediately change the
password ?

if you kinit on a Linux machine and make sure you properly change the
password of the user (as the user no as an admin), and then kinit again
with the new credentials on Solaris, does it 'solve' your segfault
issue ?

In any case a segfault in a client command is something you need to
report to your OS vendor, even if it is indirectly caused by the server
it shows a potential attack vector and it is particularly worrying in
something like kinit that may be run as root on a box.


Simo Sorce * Red Hat, Inc * New York

Freeipa-users mailing list

Reply via email to