| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for August 1, 2002Is it really The End? Last week, we stated that, due to lack of anything even close to the amount of money needed to pay the LWN staff, the publication of the LWN.net Weekly Edition would end on August 1. Since then, quite a few things have happened, including:
These developments have caused us to rethink our plans in a way we honestly had not expected. Here is a summary of where we are at. $25,000 is a nice pile of cash for a little company to have in the bank, but it is important to keep in mind that it is not enough to keep us going for all that long. Running LWN currently involves five people (Jonathan Corbet: front and Kernel pages, site code, "executive editor"; Forrest Cook: Development and Press pages, system administration; Rebecca Sobol: Distributions and Commerce pages; Dennis Tenney: Security page and corporate bureaucracy; Dave Whitinger: business development, ad sales and delivery), all of whom are experienced software engineers. These people have children and mortgages, and most work full time producing LWN. They can not be expected to do it for free, even though that is exactly what they have been doing for some months now. So the LWN staff needs things like salaries and health insurance. A minimal amount of money to provide these for the current staff is about $15,000 per month - and that level will still likely lead to loss of staff eventually. But it is a starting figure to aim for. All of our estimates on possible subscription revenue fell far below that amount. The numbers came out of gnumeric, after all, they had to be true... and besides, none of our projected numbers have ever turned out to be too conservative in the past. It was on this basis that we decided it was time to pull the plug. From the donations and feedback we have gotten, we have concluded that maybe our numbers were a little too conservative, that maybe subscriptions could bring in more than we thought. As a result, we are now thinking through plans for the implementation of a subscription-based LWN. Here, in bullet form, is the core of what we are thinking:
The decision to go to subscriptions is hard; restricted content is a difficult fit in the world of free software. We will certainly lose a great many readers by imposing subscriptions. But...if we go off the air, we lose all of our readers. It is also still not clear to us that subscriptions are sufficient to cover our costs. The thinking at the moment is that some sort of stable base of (presumably corporate) sponsorship will be required, along with whatever advertising revenue we can come up with. Without that base, it will be hard for us to proceed. The end result is that we are going to take next week away from the production of LWN to think long and hard about what we are going to do, to pursue sponsorship contacts, and to hack madly on the site code to actually implement a subscription scheme. The LWN Weekly Edition will not be published next week, though a subset may be available. At the end of the week, we hope to have a plan in place that will let us move forward, and which will stop trying the patience of our many loyal readers who have been waiting for us to get our act together. Thank you all for your overwhelming support.
A 'Statement of Assurance' on SELinux patents The June 13, 2002 LWN Weekly Edition looked at the "type enforcement" patents held by Secure Computing Corporation, and how those patents could threaten the distribution and use of the NSA SELinux distribution. Now SCC has issued a new statement with regard to those patents:
...it is the policy of Secure Computing to retain and enforce its
rights in all of its patents and other intellectual property. In
this case, we have decided to make an exception to that policy, and
to support the reasonable expectations of the open source community
SCC has also posted on its website a "statement of assurance" (in PDF format) with the details of its policy toward SELinux. This statement is worth a close look; many users may find it rather less than assuring. Here is the core of what SCC promises:
Subject to the limitations described in this Statement of
Assurance, Secure Computing will not assert the Subject Patent Rights with
respect to any use, modification, or distribution of SELinux
software that is permitted by, and is in compliance with, the terms
and conditions of Version 2 of the GNU General Public License.
In case that isn't clear enough, consider this other paragraph from the Statement:
No license is granted in this Statement of Assurance with respect
to the Subject Patents, or any other patent or other intellectual
property right, or software or other product.
Other companies which have tried to make software patents work with free software (i.e. FSMLabs, Red Hat) have licensed the patent(s) for the uses they permit. SCC has done no such thing; they just say they won't come after you if you meet the requirements. You're still legally infringing the patent, SCC just agrees to look the other way. If you were thinking about using SELinux in a product, or as part of a larger service offering, you should already be pretty nervous about a "statement of assurance" that does not actually grant the right to use the relevant patents. There is more, though. For example:
Secure Computing reserves the right to assert the Subject Patent
Rights with respect to VPN gateways, perimeter and distributed
firewalls, URL filtering, authentication and authorization for
applications, hosts, and devices, and other products, features and
functions that are beyond the scope of the Assurance. The use or
distribution of such products, features, or functions with SELinux
will not make the Assurance applicable to them.
Translated into English, this phrase is telling us that the "statement of assurance" only applies if you're not actually doing anything related to security. Or anything else, for that matter: what Linux system doesn't handle "authorization for devices"? There are a few other details that jump out when one reads this "statement of assurance":
And, of course, if you still feel that this statement is sufficiently assuring, bear in mind that it's not a contract, it's just another transient promise hosted on a web site. SCC's previous web-hosted statement, remember, was:
We plan to provide the security enhancements made to Linux under
this project to the community without restriction in full
compliance with the letter and spirit of the GPL.... There will be
no restrictions on the use of TE [type enforcement] by the Linux
open source community. We believe that leveraging the resources of
the Linux community is the best way to develop robust security for
Linux.
That promise vanished from SCC's site in June, though it can still be found via the web archive project; it has been replaced by something that, by any account, is not "without restriction." What reason is there for anybody to believe that this "statement of assurance" will be any less ephemeral? It seems that SCC is trying to create the appearance of working with the free software community without actually giving anything away. Instead, the company has used U.S. taxpayer's money to embed its own proprietary technology into what was a free system. SELinux brought a lot of energy to the secure Linux development process; among other things, it was one of the driving forces behind the development of the Linux Security Module patches, which are currently being integrated into the 2.5 kernel. SELinux itself, however, will have a hard time recovering from its patent problems. The secure Linux that we use in the future may have to based on some other technology.
No letters to the editor We did not receive much in the way of letters to the editor this week, so there is no letters page. We did, however, get a great deal of reader feedback, much of which is well worth reading. It can be found in the comments to last week's "The End" announcement, and our first and second updates posted over the last week.
Page editor: Jonathan Corbet Security Thanks for reading As we journey into an unknown future for LWN, I wanted to take this opportunity to say "Thank You" to everyone who has read the security page in 2002. It has been my pleasure to assemble information for you each week that has, I sincerely hope, been of real value.
Safe Travels,
Security news Security warning draws DMCA threat (News.com) Here's a News.com article about a new attempt to use the DMCA to suppress security vulnerability information. This time the DMCA is being wielded by HP. "In a letter sent on Monday, an HP vice president warned SnoSoft, a loosely organized research collective, that its members 'could be fined up to $500,000 and imprisoned for up to five years' for its role in publishing information on a bug that lets an intruder take over a Tru64 Unix system." (Thanks to Christof Damian).
Copyright as Cudgel (Chronicle) The Chronicle of Higher Education takes a look at the DMCA. "Since 1998, the DMCA has revealed itself to be a failure. It has not been effective at preventing piracy in cyberspace, yet it has managed to stifle harmless and even beneficial uses of material for research and teaching."
Security reports Firewall circumvention possible with Mozilla This XWT Foundation Security Advisory warns that a security flaw in JavaScript's "Same Origin Policy" (SOP) allows any JavaScript-enabled web browser, including Mozilla, to be used by an attacker to retrieve content from any server behind a firewall. The exploit depends on getting a client browser behind the firewall to visit a maliciously crafted web page.
Slackware security updates We don't have advisories from Slackware, but the latest changelog notice shows updates to mod_ssl, libmm, the DNS resolver libraries, OpenSSL, and PHP.
Fake Identd - remote root exploit vulnerability Tomi Ollila's Fake Identd is reported to have a remote root exploit vulnerability."Fake Identd is a small standalone ident server with static replies. It is designed to be suitable for firewalls, IP masquerading hosts, etc."
sendform.cgi Form Mailer v1.45 fixes directory traversal vulnerability Version 1.45 of Rod Clark's sendform.cgi Form Mailer fixes this directory transversal vulnerability reported by Steve Christey with credits to Brian Caswell and Erik Tayler.
ezContents multiple vulnerabilities Ulf Harnhammar reports multiple vulnerabilities in ezContents.
ezContents is an Open-Source website content management system based on PHP and MySQL. Features include maintaining menus and sub-menus, adding authors that write contents, permissions, workflow, and layout possibilities for the entire look of the site by simple use of settings.
php dotProject by pass authentication vulnerability dotProject Beta version 0.2.1.5 is reported to have a anthentication bypass vulnerability which allows anyone to login as Admin.
dotproject is a PHP+MySQL beta level web based project management tool that dotmarketing started in Dec. 2000 then left fallow for about 10 months. It is about 50% there (there being a very high quality product, not some half-baked simple form-into-db pages). With a little open source love, dotproject could be an MS Project killer. While dotproject was specifically designed for dotmarketing's needs, it could probably be extremely useful for any sort of service agency that requires the ability to track a project to completion.
Uninets StatsPlus 1.25 script injection vulnerabilities Brain Rawt reports script injection vulnerabilities in Uninets StatsPlus version 1.25. StatsPlus "provides a convient way to get indepth statistics about visitors to your site" which doesn't appear to have been updated since 1998.
(Proprietary product) W3Mail remote access and download vulnerabilities Tim Brown reports a "medium security hole" in W3Mail from CascadeSoft.
New vulnerabilities HylaFAX 4.1.3 fixes multiple vulnerabilities
OpenSSL remotely-exploitable buffer overflow vulnerabilities
Local root vulnerability in chfn
Temporary file vulnerability in mm library
Updated vulnerabilities Heap corruption vulnerability in at
Denial of service vulnerability in version 9 of BIND
bind buffer overflow vulnerability in DNS resolver libraries
Ethereal buffer overflow, infinite loop and memory management vulnerabilities
GNU fileutils race condition
Buffer overflow in groff
UW imapd remotely exploitable buffer overflow
Apache mod_ssl off-by-one local code execution and DoS vulnerability
libpng buffer overflow vulnerability
LPRng accepts jobs from any host.
Mailman 2.0.11 fixes two cross-site scripting vulnerabilities
PHP Remote Compromise/DOS Vulnerability
Mozilla XMLHttpRequest file disclosure vulnerability
String format bug in pam_ldap logging
Remotely exploitable vulnerability in pine
Sharutils potential privilege escalation using uudecode
Multiple vulnerabilities fixed in Squid-2.4.STABLE7
Malformed NFS packet buffer overflow vulnerability in tcpdump
Multiple vendor telnetd vulnerability
Multiple vulnerabilities in SNMP implementations
webalizer: reverse DNS buffer overflow vulnerability
Webmin/Usermin vulnerabilities
Problems with libgtop_daemon
xchat IC server based dns query vulnerability
Resources Linux Security Week and Advisory Watch The July 29nd Linux Security Week and July 26th Linux Advisory Watch newsletters from LinuxSecurity.com are available.
LinuxSecurity Magazine Online - First Edition Readers fluent in Portuguese are encouraged to check out the first issue of Linux Security Magazine from the Brazilian free project LinuxSecurity Brasil.
Testing Safety-Critical Software with AdaTEST (Linux Journal) The Linux Journal looks at the AdaTEST utility. "But how does Ada mix with Linux? In fact, it mixes quite well. The GNU Ada tool chain (GNAT) is an Ada front-end to gcc, tying Ada closely with the operating system. With standard facilities to import C functions, Ada allows for metal-near programming by importing any C functions, including system calls if need be."
Events Upcoming Security Events
For additional security-related events, included training courses (which we don't list above) and events further in the future, check out Security Focus' calendar, one of the primary resources we use for building the above list. To submit an event directly to us, please send a plain-text message to lwn@lwn.net.
Page editor: Dennis Tenney
Kernel development Release status Current release status The current development kernel is 2.5.29, which was released on July 26. It includes another set of IDE patches, a new LDM (Windows dynamic disks) driver, a number of driverfs changes, lots of fixups for the new serial driver, and, of course, lots of fixes for things that broke in the big 2.5.28 IRQ handling changes (see the July 25 LWN Kernel Page). The long format changelog is also available.Linus's BitKeeper tree (for 2.5.30) contains quite a few patches at this point. There is a change to the fork() code which allows things to be done to the child process (i.e. migration to another CPU) before it starts running. Also included is a big pile of IDE updates, more IRQ fixes, some direct I/O changes from Andrew Morton ("This code is wickedly quick"), the "strict overcommit" patch which prevents surprise "out of memory" conditions, some serial driver fixes, and an ARM update. This patch also removes the "khttpd" in-kernel web server. There is no current prepatch from Dave Jones; this posting explains why. In short: he has been busy, the current development kernels are too unstable to make patches against, and he has been getting going with BitKeeper. The current 2.5 status summary from Guillaume Boissiere came out on July 31. The current stable kernel is 2.4.18; Marcelo tried to catch us by releasing the fourth 2.4.19 release candidate just before this page went to "press," but we've learned to watch out for that kind of manouver. -rc4 contains a relatively small set of fixes for the few remaining problems that have come up; with luck, this one will turn into the real 2.4.19. The latest prepatch from Alan Cox is 2.4.19-rc3-ac5.
Kernel development news The asynchronous I/O core When Andrea Arcangeli released his 2.4.19-rc3-aa4 tree, he included an old version of Ben LaHaise's asynchronous I/O code. This led to a discussion of some features of the AIO interface, and a note from Linus wondering what had happened to the AIO project:
Note that something needs to get moving on this rsn, I'm not
interested in getting aio patches on Oct 30th. The feature freeze
may be on Halloween, but if I get some big feature just days before
I'm likely to just say "screw it".
Ben responded with a patch implementing the core part of the AIO subsystem. It is far from a full implementation - there are no device driver or filesystem changes in the patch. But it is enough to get a sense for where the AIO development is going. This patch does not, at this time, make all I/O asynchonous within the kernel (as had been discussed at Kernel Summit). Instead, devices and filesystems must implement the new aio_read, aio_write, and aio_fsync operations in the file_operations structure to be able to support asynchronous operations. This patch can thus, at this point, go into the system without actually breaking anything. That may change when the rest of the AIO code is posted. This patch provides the mechanism for submitting, tracking, and cancelling asynchronous I/O operations - actually executing those operations will come later. A new io_submit system call provides for the initiation of asynchronous I/O requests; it takes an array of structures describing what is to be done. Whenever an application wants to fire off an asynchronous read or write, it fills in a iocb structure with an "opcode," information on the buffer, etc. and passes it to io_submit. (Of course, the application will likely call a library function like aio_read which handles these details). io_submit does some validation and bookkeeping, then passes the requests on to the new file_operations methods. For now, they disappear into a cloud of missing code for execution. When the operation has completed, successfully or not, the internal function aio_complete is called with the final status. That status (and associated information) is stored in a circular buffer; applications can extract this information from the buffer with the new io_getevents system call. Interestingly, some of the structure is there to allow this circular buffer to be mapped into user space. Then applications could obtain their I/O completion information without the need for a system call. The implementation of this feature is not yet complete, however. Much of the rest of the code posted at this point concerns itself with cancellation of asynchronous I/O requests - either by application request, or when the application exits. What is missing is the implementation of the AIO operations themselves. Previous versions of this patch provided generic versions of the aio_read and aio_write operations that handled much of the low-level work. They would start by calling the standard read or write operations, but with a twist: those operations were changed to take an extra flags argument. If flags contains F_ATOMIC, the I/O operation must be completed without sleeping, or not at all. In the first case, the operation is done and the application can be notified. Life is often not that easy, though - usually it is necessary to wait for I/O operations. The application does not want to wait, of course, or it would not be using asynchronous I/O. The older AIO patch would create a kvec structure describing the operation - it contains a pointer to the physical page holding the user buffer, a length, and an offset. Then one of the new kvec_read or kvec_write operations would be called to start the work. These operations also need to be atomic (no sleeping), and must arrange to call aio_complete when the job is done. This is the part of the patch which breaks everything, of course - even devices and filesystems which have no intention of supporting asynchronous I/O must take the new flags argument on read and write. It will be interesting to see how this part of the AIO patch has changed over the last few months. If the kernel is really going to shift to asynchronous operations as the default way of doing things internally, there could be some fun surprises there.
Organizing the kernel binary interface The interface between the kernel and user space is a complicated thing. There are over 200 system calls, many of which take task-specific structures or other types as arguments. And then there is ioctl, which can be different for every driver or filesystem, and which, according to many, should be seen as hundreds of independent system calls in its own right.In the good old days, before glibc, applications included kernel header files directly to get the definitions of the structures needed for system calls. The good old days were not all that good, though; keeping the kernel header files suitable for user space use was not easy, the kernel headers brought in a lot of stuff that applications did not need, and it was not uncommon to encounter mismatches between the headers used to compile an application and the actual kernel it was running under. As a result, the rule with glibc has been to never, ever include kernel header files into application programs. The problem with this approach is that there is no longer a single definition of the interface between kernel and user space. People working on library interfaces must go hunting for structure definitions through the tangled mess of kernel header files; that is not an easy job. H. Peter Anvin, as it turns out, is working on a library interface - a small C library for the initramfs mechanism. He has come up with a relatively simple suggestion: create a new include directory (linux/abi/) for include files which encapsulate the interface between the two worlds. These files would be written so that they could be included in either kernel or user space, and they would contain only the minimal declarations needed to define the kernel interface. The idea makes a lot of sense. It would make life easier for library writers, but it would help on the kernel side as well. It is not always obvious, when editing kernel headers, that a particular structure forms part of the interface with user space. Putting the user space interface into special header files will make it harder to change that interface by mistake. Creating the abi/ directory seems like a logical part of the larger task of cleaning up the kernel's include files.
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Filesystems and block I/O
Memory management
Networking
Architecture-specific
Miscellaneous
Page editor: Jonathan Corbet
Distributions News and Editorials Distribution news for August 1, 2002 This has been a relatively slow week for distribution news. Several of the major vendors have released new versions recently, and while development has started on several new branches, these are too new to have much to report. The new Debian installer that will be used in "sarge" is a worth a look. You'll find more information in the Debian Weekly News.The minor distributions have been more active. There are a number of new releases including ClarkConnect, DemoLinux and Lycoris. There should be something there for everyone, whether you want to run Linux from a CD while at the (non-Linux) office, or want an easy desktop system for Grandma, or you are power-user and want to install everything from source. If your dream Linux system isn't mentioned on this list, then it's in the LWN Distributions list. We have some plans to improve that as well, so stay tuned, and hopefully we'll be back in two weeks.
Distribution News Debian Weekly News - July 30th, 2002 The Debian Weekly News #29 is now available. Topics this week include funding free software development and free software job opportunities in the UK.
Mandrake Linux Community Newsletter The Mandrake Linux Community Newsletter for July 25 is out. It looks at the first Mandrake Linux 9.0 beta, the latest financial results, and more.
NetBSD NetBSD has released v1.5.3 with minor security fixes.
Red Hat Bug Fix advisory for GCC 2.96-RH Red Hat has an updated version of GCC 2.96-RH available for RH 7.2 and 7.3, addressing various issues filed in bug reports.
Yellow Dog Linux Bug fix Advisory for qt Yellow Dog has updated qt packages are available. "The version of the Qt tookit that shipped with Yellow Dog Linux 2.3 contains a small bug which causes the startup time of KDE applications such as Konqueror to be quite slow. The bug also caused general UI slowness in applications such as KMail and broken preview functionality in the KDE Control Center's screensaver module. Installing the updated Qt packages resolves all of these above problems."
UnitedLinux Clan To Detail Unified ISV, Channel, Customer Programs At LinuxWorld (CRN) Here's a CRN article about UnitedLinux. "At LinuxWorld from Aug. 12-15, UnitedLinux--a consortium formed in May by four leading Linux distributors--will demonstrate an alpha version of its uniform UnitedLinux distribution and detail new programs, said Ransom Love, the former president and CEO of Caldera, who became head of Caldera's UnitedLinux operation in June."
Minor distribution updates 2-Disk Xwindow System The 2-Disk Xwindow System has released v1.4rc078 with some code cleanup.
ClarkConnect ClarkConnect has released verion 1.1. The software now comes in two versions:
DemoLinux 3.01pl5 available for download DemoLinux has released version 3.01p15. "This is the latest (and probably last) version in the 3.0x series of DemoLinux, and surely the last using the old but stable 2.2.18 kernel."
KNOPPIX KNOPPIX has released version 3.0 with major feature enhancements. The KNOPPIX website also announces the release of version 3.1, a Debian-based CD featuring Linux-Kernel 2.4.x, KDE V3.0.2, OpenOffice, and much more
Lycoris Releases Much Anticipated Desktop/LX Update 2 Lycoris has released Desktop/LX Update 2, featuring a new Internet installer, Iris, to browse and install Desktop/LX programs from the Software Gallery.
Lycoris Desktop/LX PCLinuxOnline reports that the Lycoris release of Desktop/LX Update 2 Build 46 has gone gold.
MicroBSD MicroBSD has released v0.5 with major feature enhancements.
Server optimized Linux Server optimized Linux (SoL) has released v15.00 with major feature enhancements.
VectorLinux VectorLinux has an iso image of a new beta, named SOHO. See the announcement on TuxReports.
Webfish Linux (firewall-1) Webfish Linux has released version 1.1 of its new firewall-1 branch.
Page editor: Rebecca Sobol
Development Thanks! With the future of LWN being highly uncertain at this point, I'd like to take the opportunity to say thanks to all of the LWN readers, people who have submitted material to us, and those who were kind enough to shower us with praise and donations over the years. It certainly has been an interesting and educational journey. Hopefully our efforts have helped to move Linux and open-source software forward. This grand experiment is a long way from being over.Meanwhile, I will personally continue to ponder the discorporate similarities between open-source software, solar and wind energy, homebrew beer brewing, non-commercial music, concert tape trading, and micropower radio. Open-source software will no doubt play a big roll in my future endeavors. So long and thanks for all of the fiche. (and other forms of media) -- Forrest Cook
Valgrind memory debugger 1.0.0 Developer Julian Seward has released version 1.0.0 of the Valgrind memory debugger for x86-GNU/Linux with the following inspirational note:
Programmers! Make your software Valgrind-clean. Test it with Valgrind and
fix all problems Valgrind reports. This will give you some assurance that
your code is free of a broad class of memory management errors. You may
well find undiscovered bugs, and your code will probably be more stable as
a result. It's good for your code, good for you and especially it's good
for the people who use your code.
By intercepting a number of memory related system calls, Valgrind can detect the following problems:
Valgrind is supposed to be able to check any dynamically-linked ELF x86 executable, without modification or recompilation, and it can fire up GDB when errors are encountered. Valgrind also has built-in cache profiling, which can be useful for enhancing the performance of code. The current 1.0.0 release has undergone a feature-freeze testing phase and it is considered to be stable code at this point. It has successfully been used to check a number of large applications such as KDE3, Mozilla, OpenOffice, and MySQL, to name a few applications. See the Valgrind user manual for the full documentation. Valgrind has been released under the GPL license.
System Applications Electronics Icarus Verilog snapshot 20020728 A new snapshot of the Icarus Verilog electronic simulation language compiler has been announced. The release notes are not yet available.
Web Site Development Zope Members' News The latest Zope Members' News items include announcements for ZWeatherApplet v1.0, the Zediscuss product, ZopeTestCase 0.5.0, SlideShow V0.1, My Zope 0.1, the new TriZPUG: North Carolina Zope/Python user group, and Interbase / Firebird Database Adapters.
Improving mod_perl Sites' Performance: Part 4 (O'Reilly) Stas Bekman gives some tips on the use of shared memory to improve the performance of mod_perl. "If your OS supports sharing of memory (and most sane systems do), you might save a lot of RAM by sharing it between child processe | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||