SuSE issued an advisory for this on June 24 last year:
The issue was fixed upstream in version 0.4. Fedora has provided an update to this version for Fedora 16 to fix this issue (May 18):
Mageia 1 may be affected as well.
I just submitted libgssglue-0.4-1.mga2 and libgssglue-0.1-8.1.mga1 in updates_testing.
This update fixes insecure getenv() usage in libgssglue, which could be used under some circumstances by local attackers do gain root privileges.
References for the advisory:
Testing complete on Mageia 1 i586 for the srpm
For testing, I used a Mageia 1 client under virtual box accessing
an nfs share on the host Mageia 1 system.
I'll test Mageia 2 i586 shortly.
Testing complete on Mageia 2 i586 for the srpm
Testing using an nfs share on the Mageia 2 host, accessed by the Mageia 1
vb guest, and and nfs share on the vb guest accessed by the host.
You may forget testing here, as libgssglue is only used with Kerberos support, and this is really painful to setup.
Should the packages be removed from updates testing, and this bug closed as wont fix
Whoa, I don't think that's what he meant. I think he was just saying testing normal NFS functionality won't test the library, so unless you want to go through all the pain of setting Kerberos, just make sure the package installs.
I've never used NFS with Kerberos before, but I wasn't aware it was that difficult. I'll probably get to find out pretty soon at work actually.
Ok. We still need 64 bit testing on both releases.
libgssglue installs cleanly on MGA1 64 bits.
Testing only install per comment #5
mga1-32-OK, mga2-32-OK =>
MGA1TOO, mga1-32-OK, mga2-32-OK, mga1-64-OK
Testing install on MGA2 64 bits: went fine. Validating per comment #5.
Update validated for MGA1 and MGA2. See comment #2 for packages and advisory.
MGA1TOO, mga1-32-OK, mga2-32-OK, mga1-64-OK =>
MGA1TOO, mga1-32-OK, mga2-32-OK, mga1-64-OK, mga2-64-OK