On Fri, 19 Apr 2013 02:52, mgilb...@debian.org said: >>> 1.a) Patch libgcrypt to revert commit >>> d769529a71ccda4e833f919f3c5693d25b005ff0 >> >> Urgs. That is a short sighted fix. > > That seems to be the solution the rest of the open source community is > converging toward. Short sighted is an odd categorization since it > seems to have taken 8 years to come to this conclusion.
Misunderstanding? With "a short sighted fix" I mean 1.a; that is the proposal to _revert_ commit d769529. Anyway, this commit is there for a good reason; I can't remember any details but for sure Moritz had a valid reason to do this. Those who are interested may want to do dig the gnupg/gcrypt/poldi archives. The whole mess comes from the idea that a library is able to deduce what the application wants to do without the application telling it. Now if a library is used indirectly by the application and often also from several libraries and even from the application itself, conflicts will arise. Thus we have always told that an application must be aware of _all_ code it is using in its process. Thus libraries may need to expose an interface to the application even if they are used indirectly. Using shared libraries is not easy and sometimes it is impossible to get things right (in OSes where shared libraries have been added as an afterthought). And yes, Libgcrypt is not an exception: It also does guess working and assumes that complex application won't run suid. And it tries to be as failsafe as possible by trying hard to initialize itself if the application forgot to do that. It seems the main reason for all that hassle is the ad-hoc architecture of PAM being a set of libraries instead of a daemon and a library to access that daemon (like userv(1)). PAM's track record of security problems might be an indication of that architectural problem. > Maybe some of the blogs on the issue and other comments in this bug > log would be of useful to understand why. For example: > http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html While we are in the business of refreshing our URL memories, let me follow up with: http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198 Florian Weimer comes to the same conclusion regarding the PAM architecture but also asked why we still need a suid for mlock. The simple reason is that some installations still use suid(e.g. gpg) and rely on Libgcrypt dropping the privileges. Thus we can't change that. A solution would be that the application explicitly tells us not to drop the privileges. libpam can't do that because it does not know anything about the application. But wait, the bug at hand is about a specific application and thus sudo would be able to tell libgcrypt what to do. Adding a global flag to Libgcrypt to skip privilege dropping will not be hard; let me know if this could be a way forward. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
