Bugzilla Bug 95283

mit-krb-1.4 is using the system libcom_err.so.2 (and the provided compile_et).

The compile_et has a broken awk script that makes applications fiddle directly
with _et_list so that calls to unregister their error table later makes the
program abort with an invalid free (glibc detected invalid pointer in free, blabla).

Since libcom_err is already providing a clean handler to add an error table, why
does its awk script for client code generation not use it?

The attached patches to the com_err ebuild and to /usr/share/et/et_c.awk fix the
problem.

The problem showed up, for example with
- app-crypt/mit_krb5-1.4
- app-crypt/pam_krb5-20030601-r1

with the following system-auth
#%PAM-1.0

auth       required     /lib64/security/pam_env.so
auth       sufficient   /lib64/security/pam_unix.so likeauth nullok broken_shadow
auth       sufficient   /lib64/security/pam_krb5.so use_first_pass
auth       required     /lib64/security/pam_deny.so

account    sufficient   /lib64/security/pam_krb5.so
account    required     /lib64/security/pam_unix.so broken_shadow
account    required     /lib64/security/pam_tally.so deny=5 reset

password   required     /lib64/security/pam_cracklib.so retry=3
password   sufficient   /lib64/security/pam_krb5.so use_authtok
password   sufficient   /lib64/security/pam_unix.so nullok md5 shadow use_authtok
password   required     /lib64/security/pam_deny.so

session    required     /lib64/security/pam_limits.so
session    optional     /lib64/security/pam_krb5.so
session    required     /lib64/security/pam_unix.so broken_shadow

--

After that "su" stops working with the metioned glibc failed assertion abort.


Reproducible: Always
Steps to Reproduce:

Created an attachment (id=60750) [details]
ebuild patch, adds epatch command for the next patch

Created an attachment (id=60751) [details]
goes into the ${FILESDIR}

The filename for the second patch for /usr/portage/sys-libs/com_err/files/
should be: com_err-1.37-et_c_awk.patch

Analogous bug report in e2fsprogs bug tracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=1150146&group_id=2406&atid=102406

Christophe, what's the latest on this then?

Upstream has acknowledged the problem.
My fix is okay in theory, but practically it might introduce other problems
(they are worried about binary compatibility with other libcom_err
implementations that don't have the dynamic table allocation functions at all).
I don't know what's going on exactly at the moment, I'll ask again.

why do we have a stable e2fsprogs port which doesn't compile (without our
patch).  Can you make a stable e2fsprogs ebuild for that?

Thanks,
Martin

PS.  I hope to see a stable one the next days...

Upstream has resolved the problems in e2fsprogs-1.38.

A workaround for programs compiled with the old compile_et as well as an
improved compile_et.

great, thanks

i added 1.38 yesterday so ... :)

*** Bug 98303 has been marked as a duplicate of this bug. ***

Any chance to change from "~alpha" to "alpha"?

I just built it and there are no obvious problems.