On Thu, Apr 28, 2011 at 03:09:48PM +0200, Simon Josefsson wrote: > Roger Leigh <rleigh@codelibre.net> writes: > > > libgcrypt has some horrendous bugs which upstream refuse to fix, > > for example the broken behaviour relating to setuid binaries > > discussed previously here, and the hard coded behaviour which > > makes it unsuitable for use in general programs. See > > > > "libgcrypt brain dead?" > > 3c5cf5261003081534s5202413dw4d93c80db1a30150@mail.gmail.com > > > > Until these major issues are fixed, it's simply unusable. > > It appears to be usable by a lot of projects and people, so that seems > like an exaggeration. If I have understood Werner correctly, he > believes that it is the setuid binaries that are broken and should be > fixed. It is usable if your program meets the hardcoded assumptions made in libgcrypt. If it does not, it breaks badly. This is why it's not *generally* usable, but only in specific cases. Werner's assertions WRT setuid binaries are plain wrong. gcrypt takes it upon itself to drop setuid privs because it makes the *assumption* that you are setuid solely to use mlock(). What if you are setuid for some other reason? In every other case, gcrypt drops root privs when you might still want them. And in the case that gcrypt is used as a side effect of being linked into an NSS module, it can happen during many glibc calls. That is totally broken. Example: schroot is setuid and needs to be setuid to chroot() and setuid() to the specified user. If you have a NSS module linked with gcrypt, a simple getpwent call results in a premature dropping of root privs, and the program subsequently aborts because it no longer has the privs to do its job. gcrypt is entirely responsible for that breakage by making a broken assumption. It's not the job of a *library function* to alter *global process state* as a side effect. setuid binaries which are setuid solely for mlock() need to drop root privs themselves, or have some means for them to instruct gcrypt to drop them explicitly on request. Doing it by default is poor practice, and breaks things as that thread shows. This is a fundamental design flaw in gcrypt which needs fixing before it is suitable for general purpose use. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature