On Sun, May 01, 2011 at 02:29:39PM +0200, Andreas Metzler wrote: > Simon Josefsson <simon@josefsson.org> wrote: > [...] > > 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. > [...] > > Hello, > I would rather say he considers NSS (or PAM) fundamentally broken, > because a tiny, scrutinized SUID binary ends up with *huge* amounts of > external unrelated code in its address space after getpwnam(). This is something I can understand to an extent. Having a single service providing access to the NSS databases would offer some advantages. Unfortunately, I've only ever heard bad things about nscd. If we could move to having a central service, rather than having every process load in a pile of extra libraries, I would probably be in favour of it. If would make some things, such as NSS queries inside chroots, much more efficient and robust. However... that's not the reality right now, and it never has been. Even if the NSS situation changes, surely it's immediately obvious that a random library function should not tamper with the uid of a process as a side-effect? Unless the caller explicitly requested dropping of root privs, no library has *any* business in changing it. The reality is that only the main program knows what uid and other privileges it wants and needs to function; a library can't make any assumptions about what may or may not be appropriate here. It could be instructed by the main program to drop privs, but it can't unilaterally make that decision on its own, which is what libgcrypt is doing right now. > Also libgcrypt does seem to be designed to be used indirectly (via > gnutls) without knowing and caring about it. (Threading, secmem). > Which is why about 50% of all gnutls-using packages are using > gcry_control. This is the root cause, I think. libgcrypt was developed as part of gnutls, and although it's a separate library, it's insufficiently generalised. It's implicitly doing things the way gnutls wanted them doing, and rather than making the library completely general and moving special case logic into the callers (or only doing it upon specific request), we're in the situation we have now: breakage. Using it indirectly is not a solution; the solution is to fix the library to work sensibly by default, and fix up the client code relying on the assumptions made by the library so that they can be removed and/or made non-default. 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