Re: integrating PAM module into nss-ldapd (RFH)
Arthur de Jong wrote: Hello list (I've put a couple of people in Bcc to try to get more feedback), I'm working on integrating a PAM module into nss-ldapd and am looking for input on this. The PAM module was kindly provided by Howard Chu from the OpenLDAP project but I'm still working on the server part. (more info on nss-ldapd: http://packages.debian.org/nss-ldapd) With this new functionality I'm planning to generate three binary packages (instead of the now one): libnss-ldapd (the NSS module), libpam-ldapd (the PAM module) and nslcd (the daemon). The reason for this split is that some users may want to stick with the other PAM module. Also the OpenLDAP people are working on an overlay that could replace the nslcd part (but it's up to the OpenLDAP maintainers if they want to provide such a package). The nssov manpage describes some of the motivation for this work. http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules/nssov/slapo-nssov.5?rev=1.3 Note that the OpenLDAP Project only provides source distributions; it's up to 3rd parties to provide packages. Symas Corp. is in the process of testing packages for this code now; I know that some of the SuSE folks looked at an earlier version but I'm not sure if they went anywhere with it. Also, I'm looking for people who are willing to spend some time on nss-ldapd. I could use some help with the PAM packaging part, I know libpam-runtime was changed recently so if anyone can help to get the the PAM packaging into shape that would be great. Since nss-ldapd seems to be used more often now, having a co-maintainer for the package would really help. There is still enough development work to be done but also packaging work with the upcoming split. Another important part where I would really welcome suggestions is a better name for the software. I've seen some confusion over the current name (people not noticing the d at the end) and with the integration of PAM functionality the name no longer covers the functionality. Current work on integrating the PAM functionality can be tracked here: http://arthurenhella.demon.nl/svn/nss-ldapd/nss-pam-ldapd/ http://arthurenhella.demon.nl/viewvc/nss-ldapd/nss-pam-ldapd/ Any comments and suggestions are very much appreciated. Thanks. The name is alwas the tricky part huh... ldapauth? nss-pam-ldapd is at least recognizable... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Berkeley DB 6.0 license change to AGPLv3
n in the modern world. MDB object code is a tiny fraction of BDB, and by adopting a memory-mapped architecture and dispensing with caching and locking it relies on modern operating system features rather than trying to implement them internally. This means greatly increased performance and very much smaller windows for corruption to occur. MDB has very clean support for concurrency compared to BDB, which makes it much more suitable for modern applications. There is an technical discussion of MDB here: http://symas.com/mdb/20120829-LinuxCon-MDB-txt.pdf . Some performance data has been published, one simple test that has a minimum of imaginable bias is to compare the SQLite3 API that comes with Oracle BDB with the SQLite3 ported to MDB. The other obvious speed test (that has had reproducible data published) is with OpenLDAP, which has pluggable back ends including both BDB and MDB. We can provide plenty more documentation on LMDB performance and reliability if desired. I'll be delighted if someone can suggest something that is even more suitable than MDB, but so far I haven't seen it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d305b7.8030...@symas.com
Re: boot ordering and resolvconf
Don Armstrong wrote: On Tue, 02 Jul 2013, Tollef Fog Heen wrote: Automatic processes overwrite explicit admin setups. If /etc/resolv.conf is a symlink to somewhere else, then it's appropriate for automatic processes to override it by writing to "somewhere else". If it's not a symlink, then it shouldn't be overridden. That seems pretty plain, but Ubuntu/Networkmanager routinely ignore this fact. I'm a bit surprised that this conversation still needs to happen today. It was a constant annoyance when I was using Ubuntu. (I finally switched to Arch back in January this year.) Networkmanager seems to have been the root of most of my complaints; its authors seem to believe that their code knows better than a machine's sysadmin how the machine should be operated. https://mail.gnome.org/archives/networkmanager-list/2008-September/msg00189.html The sensible thing to do is let something like dnsmasq do all resolver management. I first proposed this change ~5 years ago https://mail.gnome.org/archives/networkmanager-list/2008-September/msg00042.html It's a topic that comes up perennially. https://mail.gnome.org/archives/networkmanager-list/2009-April/msg00157.html https://mail.gnome.org/archives/networkmanager-list/2011-January/msg00020.html https://mail.gnome.org/archives/networkmanager-list/2012-April/msg00072.html Providing solutions for other tools, e.g. dhclient or pppd is pretty trivial too. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q2/003009.html We're well into the 2nd decade of the 21st century. These problems shouldn't exist any more. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d32c30.1030...@symas.com
Re: Berkeley DB 6.0 license change to AGPLv3
Florian Weimer wrote: * Howard Chu: We can provide plenty more documentation on LMDB performance and reliability if desired. Can you cope with incompletely written pages (e.g., only the first 512 bytes of a page is written) or write reordering between fsyncs? Berkeley DB doesn't deal with torn writes, either, but it can deal with write reordering. The latter is what makes the checkpoints so expensive, but I don't think there's a way around that. You can spread out the writes (PostgreSQL tries to do that, but it is not entirely successful because of kernel API limitations), but then you risk doing additional writes which are not strictly required for durability. We require that fsync() (actually fdatasync()) doesn't lie. Data pages can be written in any order, as long as all outstanding data pages are actually written by the time fsync returns. Given this constraint, you can pull the power on a drive and the DB will still be fine. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d3377a.7020...@symas.com
Re: Berkeley DB 6.0 license change to AGPLv3
Florian Weimer wrote: * Howard Chu: We require that fsync() (actually fdatasync()) doesn't lie. Data pages can be written in any order, as long as all outstanding data pages are actually written by the time fsync returns. Given this constraint, you can pull the power on a drive and the DB will still be fine. And you do an fsync() as part of every transaction commit? Doesn't this force quite a bit of non-sequential writes? (Page 0 or 1, plus all the pages written to during the transaction.) Yes, but in fact we send writes to the OS in sorted order (ascending page number). Net result is that performance on an HDD is better than random seek time because there are no head direction reversals in the middle of a commit. (Assuming the underlying I/O scheduler doesn't get in the way. Usually we use the noop scheduler.) Also we allocate and reuse pages in linear order, so very frequently our writes are purely sequential. A trace of disk activity on writes would be reminiscent of an old style typewriter - gradual progress from 0/1 upward followed by a carriage return. It's curious that this results in competitive write performance. (WAL-based systems only need one sequential write during transaction commit.) Perhaps spreading out the writes at commit is worth all the seeking and the potentially redudant writes because it avoids write-induced stalls at checkpoints (or compaction events or whatever databases do to look good in benchmarks but fall over in practice :-). LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of source, there's nowhere to hide any tricks anyway.) This is as apples-to-apples real world as it gets, since the BDB backends in OpenLDAP have been around for over a decade and tuned to the Nth degree. http://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance We've spent years fighting with bad behaviors in DBs. We have none of them in LMDB. http://www.anchor.com.au/blog/2013/05/second-strike-with-lightning/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d3427a.50...@symas.com
Re: boot ordering and resolvconf
Steve Langasek wrote: On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote: Don Armstrong wrote: On Tue, 02 Jul 2013, Tollef Fog Heen wrote: Automatic processes overwrite explicit admin setups. If /etc/resolv.conf is a symlink to somewhere else, then it's appropriate for automatic processes to override it by writing to "somewhere else". If it's not a symlink, then it shouldn't be overridden. That seems pretty plain, but Ubuntu/Networkmanager routinely ignore this fact. I'm not sure why you group Ubuntu and NetworkManager together here. Ubuntu has been using dnsmasq and resolvconf on the desktop (and resolvconf alone on the server) since the 12.04 release specifically to provide a coherent architecture and get away from NM's past bad behavior of changing files in /etc out from under the admin. http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ *By default*, all Ubuntu systems running a newer release will have /etc/resolv.conf as a symlink to /run to ensure the system behaves sensibly (correct DNS server settings with or without dnsmasq running; honoring DNS server settings configured in /etc/network/interfaces; and so on). But if this symlink is really bothering you, you can make /etc/resolv.conf a real file and resolvconf won't mess with it any further. That sounds nice, but my old laptop running 12.04 is still getting its /etc/resolv.conf overwritten by networkmanager, I just took a look and the timestamp on it is from a few hours ago. Anyway, having just now read the launchpad blueprint, I'm sorry I missed this discussion when I was at that UDS. resolvconf is an unnecessary layer here, dnsmasq handles all of the interface-specific knowledge already. Patching dhclient's interface scripts to talk to dnsmasq over DBUS is trivial (see link in my previous email) and anything else that wants to touch it can be fixed easily as well. virtmanager's use of dnsmasq is a non-issue since it binds its instances to its specific virtual networks already. They all just need to know to forward to the main dnsmasq on 127.0.0.1 when handling their clients' requests. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d34b3d@symas.com
Re: Berkeley DB 6.0 license change to AGPLv3
Florian Weimer wrote: * Howard Chu: LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of source, there's nowhere to hide any tricks anyway.) Okay, I found a snag: the 511 bytes limit on the key size. Berkeley DB's disk format does not impose a limit on key or value size (at least for B-trees). For some applications, this will introduce new error conditions, and working around this limitation requires reworking the database schema. True. There's a bit of leeway here, we can raise the key size to ~1/2 the page size if necessary. But ultimately, we don't support keys that don't fit in a single page and there are no plans to add such support. If we see enough apps that can't live with this, we may revisit the situation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d883ab.8000...@symas.com
Re: Berkeley DB 6.0 license change to AGPLv3
Scott Kitterman wrote: On Saturday, July 06, 2013 01:52:59 PM Howard Chu wrote: Florian Weimer wrote: * Howard Chu: LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of source, there's nowhere to hide any tricks anyway.) Okay, I found a snag: the 511 bytes limit on the key size. Berkeley DB's disk format does not impose a limit on key or value size (at least for B-trees). For some applications, this will introduce new error conditions, and working around this limitation requires reworking the database schema. True. There's a bit of leeway here, we can raise the key size to ~1/2 the page size if necessary. But ultimately, we don't support keys that don't fit in a single page and there are no plans to add such support. If we see enough apps that can't live with this, we may revisit the situation. I did go back and look at the plans for mdb integration in Postfix, since it's my MTA of choice. It does seem that there are some barriers to adoption: http://www.postfix.com/LMDB_README.html Are there any plans to address these issues? Yes http://www.openldap.org/lists/openldap-devel/201303/msg2.html we've been working with Wietse Venema and plan to have this addressed in our upcoming 0.9.7 LMDB release. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51de90ba.2060...@symas.com
Re: AGPLv3 Compliance and Debian Users
Clint Byrum wrote: Excerpts from Richard Fontana's message of 2013-07-11 10:45:00 -0700: On Thu, Jul 11, 2013 at 08:27:31AM -0700, Clint Byrum wrote: Excerpts from Richard Fontana's message of 2013-07-11 06:55:12 -0700: On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote: I'm no expert but that would be my interpretation. Also when I asked about the basis of the network part of the AGPL during the GPLv3 talk at DebConf10 in NYC, Bradley said the AGPL was specifically based on modification, _not_ on public performance or other use. You have to make the source available in this case. Otherwise it would be a trivial way around the AGPL (just have a third party modify the program and give it to you). Co-author of AGPLv3 here, including the section at issue. You do not have to make the source available in this case, in general. In unusual cases of circumvention, like what I believe you are suggesting, the answer might arguably be different, but in the context of ordinary Linux distributions, when a user gets AGPLv3-licensed software that the *distro* has modified, that software is *unmodified* from the standpoint of that user downstream from the distro and therefore the user needs to do something to trigger the section 13 requirement. Otherwise you have to explain why modification was made to be the trigger. If the modified/unmodified distinction was meant to be meaningless, section 13 would have been drafted not to make any reference to modification. Indeed, other Affero-like licenses typically are broader than AGPLv3 in the sense that they work by redefinition of 'distribution' and thus are not limited to cases where the user has modified the software. This approach was specifically rejected when AGPLv3 was being drafted. So are you suggesting that the AGPL's protections against commercial takeover are basically moot? No. The main problem I have been seeing is in the opposite direction: overbroad interpretations of AGPLv3, one of the reasons I am chiming in here. It is the tendency to overbreadth that is tragic. How would the AGPL be applied in this scenario: Company A starts a business based on unmodified MediaGoblin. They hire a firm, Consultants-R-Us, to manage their MediaGoblin code base and develop a new new video encoder. Their contract with Consultants-R-Us keeps ownership of all code in Consultants-R-Us name, and C-R-U simply gives a tarball to Company A which they then use to serve users. Can we honestly say that Company A modified the software? Possibly, in that case -- but that's entirely different from the distro packaging scenario. Right, I want to understand AGPL's motivations is all. I used to put similar terms on my code, back before the GPL existed. Essentially: If you modify this code, you must send your modifications back to me (the original author). The motivation is that if you fixed a bug or improved the code, you should make your improvements available to me, and I subsequently make them available to the user base at large in my next release. I don't consider this a terrible restriction - if you're using my code that you got for free, and are deriving value from it, and find a way to make it better, I think you owe it to everyone to release your improvement freely as well. If not, then what is the point of the AGPL? To protect C-R-U? I am not suggesting that this is absolutely not modification by Company A. However, to a non-lawyer like me, it sure _looks_ like a big hole. I don't see any hole. If C-R-U did the modifications then they are obligated to publish the source code, by virtue of the fact that giving the modified code to Company A is distributing it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51df0553.8080...@symas.com
Re: AGPLv3 Compliance and Debian Users
Paul Tagliamonte wrote: On Thu, Jul 11, 2013 at 12:19:47PM -0700, Howard Chu wrote: Right, I want to understand AGPL's motivations is all. I used to put similar terms on my code, back before the GPL existed. Essentially: If you modify this code, you must send your modifications back to me (the original author). The motivation is that if you fixed a bug or improved the code, you should make your improvements available to me, and I subsequently make them available to the user base at large in my next release. I don't consider this a terrible restriction - if you're using my Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] [1]: The Dissident test [2]: The Desert Island test Sure, but #2 is stupid. We didn't say "must send changes back immediately." Nor would we wish any such thing; if you're in the middle of making a long series of changes we obviously want to wait until the changes are completed and have settled down. Otherwise someone could make a case that the changes should be sent back the instant they are written, one keystroke at a time, which is ludicrous. Send changes back in a timely manner. You obtained the software somehow; therefore at some point in time a distribution channel was available to you. The next time such channel is available, send your changes back. If you're stuck on a desert island and die before such channel reopens, no one's going to sue you. I'd say #1 is borderline stupid. It is worded such that it only applies to hiding existence of a system from the government. Fair enough; I'm not the government. I've accepted many patches from anonymous senders for various code (see http://rtmpdump.mplayerhq.hu/ for example: RTMP Dump v2.4 (C) 2009 Andrej Stepanchuk (C) 2009-2011 Howard Chu (C) 2010 2a665470ced7adb7156fcef47f8199a6371c117b8a79e399a2771e0b36384090 (C) 2011 33ae1ce77301f4b4494faaa5f609f3c48b9dcf82 License: GPLv2 librtmp license: LGPLv2.1 http://rtmpdump.mplayerhq.hu/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51df0d1d@symas.com
Re: AGPLv3 Compliance and Debian Users
Steve Langasek wrote: On Thu, Jul 11, 2013 at 12:53:01PM -0700, Howard Chu wrote: Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] [1]: The Dissident test [2]: The Desert Island test Sure, but #2 is stupid. We didn't say "must send changes back immediately." Nor would we wish any such thing; if you're in the middle of making a long series of changes we obviously want to wait until the changes are completed and have settled down. Otherwise someone could make a case that the changes should be sent back the instant they are written, one keystroke at a time, which is ludicrous. Send changes back in a timely manner. You obtained the software somehow; therefore at some point in time a distribution channel was available to you. The next time such channel is available, send your changes back. If you're stuck on a desert island and die before such channel reopens, no one's going to sue you. I'd say #1 is borderline stupid. It is worded such that it only applies to hiding existence of a system from the government. Fair enough; I'm not the government. That's not the point. The purpose of the Dissident Test is to demonstrate that distribution channels for software are not necessarily symmetric; it may be very easy for you to distribute the software, but very hard/expensive/dangerous for a recipient to distribute their modifications back to you. In the specific case of the Dissident Test, the unreasonable cost of returning the changes upstream - as opposed to distributing them to whoever you happen to be distributing binaries to (possibly no one) - is that sending those communications back may give hostile authorities information you don't want them to have, such as your location, details about the software you're modifying, or even simply the fact that you're doing something that you care about encrypting to keep them from prying. Even if you aren't otherwise doing anything the government disapproves of, the mere act of sending these changes upstream might get you labelled a spy. This is still an unreasonable test. Again, it ignores the element of time. Send your changes at your earliest convenience. If the NSA is breathing down your neck, "convenience" might be a long time away, but that's understandable. This is one example of why Debian says it's ok for a license to require modifications to be distributed to your downstreams, but not ok to require those changes be sent to a particular party. Users should not have to choose between complying with the license and being safe from their government; they should be *free* to exercise their rights on the code in Debian, even when they aren't free in other aspects of their lives that we don't have control over. Freedom always has a price. The price of benefiting from free software should be that you help others benefit from it too. Absolving recipients of all such responsibility merely encourages parasites. Progress happens faster when everyone pitches in, there shouldn't be just a few people creating and everyone else tagging along for the ride. Even here http://people.debian.org/~bap/dfsg-faq.html 12.A.k "This freedom is one of the most important driving factors for progress in computing---and we like progress." That sentence is not talking about this particular point but the underlying concept remains - the goal for all of this is to encourage progress, not hinder it. Hoarding improvements to yourself hinders progress for society as a whole. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51df3f52.9030...@symas.com
Re: AGPLv3 Compliance and Debian Users
Steve Langasek wrote: Let's not forget that Al Capone was convicted not for murder, racketeering, or bootlegging, but for tax evasion; and that the US tax code specifies where on your tax form you are required to report income from the sale of illegal drugs. It would be ironic for a dissident to evade capture and prosecution for years, only to finally be brought up on charges of criminal copyright infringement (with or without the consent of the copyright holder!) for failing to submit their changes upstream while operating clandestinely. Indeed. If you're a dissident fighting your own government, then complying with a license that can only be enforced by a government agency is probably the least of your worries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51df60f3.10...@symas.com
Re: Debian openssh option review: considering splitting out GSS-API key exchange
Damien Miller wrote: > Another thing we're considering in OpenSSH is changing how we integrate > with PAM. PAM's API demands loading modules into the authenticating > process' address space, but obviously we've just been reminded that this > is risky. This was a long-standing problem with pam/nss-ldap, which we solved by moving all of the actual libldap invocations to a separate nslcd process, and only communicated to it across a unix domain socket via stubs in the pam/nss modules. Mixing instances of libraries that applications call directly, with instances loaded implicitly by system-level mechanisms, was always a bad idea and caused endless problems, even without malicious attackers. > I think that I would prefer to move to a model where there PAM auth and > account modules run in a helper process, and only the session module > runs in the unprivileged post-auth sshd process. We could probably generalize the stub wrapping that we used for nss/pam-ldapd / nslcd to be a generic interface to a standalone pamd that actually loads the pam modules. Should be a simple job. > This means that PAM auth/account modules and their transitive library > dependencies cannot affect the sshd address space. They would still > likely need to run with privilege, could still fail permissively in > unwanted situations and might still be able to cause problems directly > (e.g. opening a reverse shell from the PAM module itself), but they > would no longer have direct access to the contents of sshd network > traffic, signatures, etc that are extremely useful in building NOBUS > (https://en.wikipedia.org/wiki/NOBUS) backdoors like the xv one. > > Where this gets challenging is that some PAM modules make assumptions > that the auth, account and session modules all run in the same address > space. These would break until re-architected to pass things explicitly, > e.g. via environment variables, temp files, etc. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
