UNIX File System Security: Part 1 Previous Screen Douglas G

Total Page:16

File Type:pdf, Size:1020Kb

UNIX File System Security: Part 1 Previous Screen Douglas G 84-01-17 UNIX File System Security: Part 1 Previous screen Douglas G. Conorich Payoff The most important issue facing the UNIX system security administrator is understanding the key security issues surrounding the UNIX file system. The UNIX file system has built- in security features and utilities that can either enhance file security or create areas of exposure, depending on how they are set. The file permissions bits are the final line of defense, allowing the user to control the type of access (e.g., read, write, and execute) users can have to files and directories. This article, the first in a two-part series, examines how file permissions are set and their impact on security; specific controls and monitoring techniques are discussed. The second article in this series will address how to mitigate the risks associated with startup files; it will also discuss the appropriate controls for such special files as device and link files and describe how to use a checklist file to monitor changes to files. Introduction All information pertaining to a UNIX data file, with the exception of the file name, is listed in the information node (i-node). The i-node contains the file s permissions, link count, ownership, size, and the a-time, m-time and c-time of the file. (The a-time is the last time the file was read; the m-time is the last time the file was written or modified; and the c-time is the last time the i-node was written or modified.) Each i-node is distinguished by a unique number called the i-node number. The i-node numbers range from 2 (the root i- node) to 65535. The i-node acts as a pointer to the actual file data. A directory is a special type of file that contains a listing of the i-node numbers and their related file names. Directories have their own set of permission bits and their own i-node number. The directory provides the link between the file name and the i-node number. File Permissions Each file and directory has two bytes allocated to it that are associated with the file permissions and identity. These two bytes are divided into octals (i.e., sets of three bits whose additive value ranges from 0 to 7). The octals are arranged as shown in Exhibit 1. The extra bit and the high order (fifth)octal determine the file type (e.g., file, directory, special, character device, block device, or link). The next octal (the fourth)grants increased permissions to the file (set-user-id, set- group-id, or sticky bits). The last three octals determine the permissions for the file. The third, second, and first octals set the permissions for the user (including the owner), the group, and all others (i.e., the world), respectively. File Permission Bit Structure There are three permissions for each of the three user areas: user, group, and world, on each file and directory: · r (read). This permission bit allows the file to be accessed, or copied. In the case of a directory, this permission bit allows the names of the files in the directory to be listed. · w (write). This permission bit allows the file contents to be modified. In order for a Previous screen file to be created, deleted, or renamed, the write permission must be set on the parent directory. · x (execute). This permission bit allows the file or directory to be executed. Programs contained in the file can be run. Binary files (e.g., compiled programs) require only the execute bit to be set. Other programs, such as shell scripts, must also have the read permission bit set to run, because the shell under which the program is running must read the program in order to run it. The execute permission allows directories to be accessed (e.g., to search the directory). Without this permission set, the user cannot change directory. (It should be noted that for directories, the read permission bit allows the files to be visible and the execute bit makes them accessible.) Special features may be given to a file or directory by setting the bits in the fourth octal: · suid (set-user-id). With this permission bit set, the user executing the file gains the permissions of the owner of the file allowing users to execute programs they would not normally have the privilege to run. While running the program, the user's effective ID is that of the owner of the file. For this reason, it is extremely important that the program cannot execute a shell (i.e., shell escape). If the person shell escapes, they retain the effective ID of the suid program. If the owner of the program is root, shell escapes could lead to a devastating breach of the integrity of the system and data. Examples of suid programs are passwd, mail, and ps.The suid bit has no meaning for files, and directories that are not executable. · sgid (set-group-id). As with the suid bit, the user executing the file gains the permissions of the owner s group associated with the file. The sgid bit has no meaning for files that are not executable. SunOS gives special meaning to the sgid bit set on directories. Under the System V rules, a file created in a directory is assigned the group ID of that user as defined in the/etc/passwdfile. The UNIX Berkeley Software Distribution (BSD) method assigns the group ID of the directory in which it is created. Without the sgid bit set, the group is assigned in accordance with the UNIX System V mechanism. The sgid bit set causes the BSD mechanism to be used. · sticky bit. With the sticky bit set, the text image of a binary file remains in memory. The sticky bit was designed to increase the performance of commonly called binaries. With the text image already in memory, the program will start up quicker in subsequent executions. Problems can be encountered if too many files are sticky; memory or swap space could be filled with overuse. Since directories are not executable(they are only read into memory when listed or searched), retaining them in memory has no purpose. SunOS and System V versions of UNIX have given the sticky bit meaning on directories. If the sticky bit is set on a directory that is group- or world-writable, only files owned by that user may be moved or removed. This can give more security to directories that must be writable by all. The fifth octal and the extra bit determine the file type. A dash(–) is used to designate an ordinary file. The d designator shows that a file is a directory. The b, c, s and the p are used with special device files. They represent block devices, character devices, sockets, and ports, respectively. Listing Directories Previous screen The ls command is used to list the contents of directories. The lscommand can be executed with several options to produce various outputs. Typing ls without arguments creates a listing of only the file names, as shown in this example: $ ls /usr/doug BART chicken lock.c thirty_days FILES craker_pgm policy tmp appendix_d holes pwage check_files lock pwage.c The -i argument lists the files and their i-node numbers, as shown here: ls -i /user/doug 23564 BART 23577 craker_pgm 23593 pwage 23591 FILES 23574 holes 23589 pwage.c 23587 appendix_d 23586 lock 23595 thirty_days 23575 check_files 23576 lock.c 23579 chicken 23598 policy To produce a long listing of the directory, add the -l argument. A-a can be used to print all the file, including those that would normally be hidden ( dot files, named because of the leading dot). Some systems include the group name in the long listing; other versions of UNIX require the use of a -g argument. ls -lag /usr/doug total 256 drwx--x--x5 doug 2011024 Mar 28 06:39 . drwxr-sr-x20 root 2011536 Mar 19 17:01 .. -rw------ -1 doug doug148 Mar 28 06:39 .Xauthority -rw-r--r--1 doug doug217 Jun 30 1992 .cshrc -rw-r--r--1 doug doug294 Nov 18 21:49 .login -rw-r--r--1 doug 201900 Oct 22 16:22 .mailrc -rw-r--r--1 doug doug 186 May 18 1992 .profile -rw-r--r--1 doug 20112 Sep 3 1992 .rhosts drwxr-xr-x11 doug 201512 Feb 25 16:45 .wastebasket -r-------1 doug kmem44 Mar 28 06:39 .xnews.tiger:0 -rw-r--r--1 doug doug790 May 22 1992 BART -rw-r--r--1 doug 2015527 Mar 28 02:58 FILES -rw-r--r--1 doug 2013007 Oct 13 12:34 appendix_d -rw-r--r--1 doug 2012363 Aug 25 1992 check_files -rw-r--r--1 doug 2011253 Sep 4 1992 chicken -rw-r--r--1 doug 2014446 Aug 25 1992 craker_pgm -rwsr-xr-x 1 root 2011420 Aug 25 1992 holes -rwxr-xr-x1 doug 20124576 Sep 21 1992 lock -rw-r--r--1 doug 201818 Sep 21 1992 lock.c -rw-r--r--1 doug 20154757 Aug 12 1992 policy -rwxr-xr-x1 doug 20124576 Sep 29 15:36 pwage -rw-r--r--1 doug 201941 Oct 22 16:16 pwage.c -rwxr-xr-x1 root 201244 Dec 18 15:59 thirty_days The file type and permissions are displayed in the first field followed by the number of links to the file, the file owner, the file s group, the file size, the date and time of the last modification, and the file name.
Recommended publications
  • File Formats
    man pages section 4: File Formats Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 817–3945–10 September 2004 Copyright 2004 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
    [Show full text]
  • Dealing with Document Size Limits
    Dealing with Document Size Limits Introduction The Electronic Case Filing system will not accept PDF documents larger than ten megabytes (MB). If the document size is less than 10 MB, it can be filed electronically just as it is. If it is larger than 10 MB, it will need to be divided into two or more documents, with each document being less than 10 MB. Word Processing Documents Documents created with a word processing program (such as WordPerfect or Microsoft Word) and correctly converted to PDF will generally be smaller than a scanned document. Because of variances in software, usage, and content, it is difficult to estimate the number of pages that would constitute 10 MB. (Note: See “Verifying File Size” below and for larger documents, see “Splitting PDF Documents into Multiple Documents” below.) Scanned Documents Although the judges’ Filing Preferences indicate a preference for conversion of documents rather than scanning, it will be necessary to scan some documents for filing, e.g., evidentiary attachments must be scanned. Here are some things to remember: • Documents scanned to PDF are generally much larger than those converted through a word processor. • While embedded fonts may be necessary for special situations, e.g., trademark, they will increase the file size. • If graphs or color photos are included, just a few pages can easily exceed the 10 MB limit. Here are some guidelines: • The court’s standard scanner resolution is 300 dots per inch (DPI). Avoid using higher resolutions as this will create much larger file sizes. • Normally, the output should be set to black and white.
    [Show full text]
  • Software Distributor Administration Guide for HP-UX 11I
    Software Distributor Administration Guide for HP-UX 11i HP Computers Manufacturing Part Number: B2355-90754 June 2002, Edition 3 © Copyright 2002 Hewlett-Packard Company. Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local Sales and Service Office. Restricted Rights Legend Use, duplication or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies. HEWLETT-PACKARD COMPANY 3000 Hanover Street Palo Alto, California 94304 U.S.A. Use of this document and any supporting software media supplied for this pack is restricted to this product only. Additional copies of the programs may be made for security and back-up purposes only. Resale of the programs, in their present form or with alterations, is expressly prohibited. Copyright Notice Copyright 1997-2002 Hewlett-Packard Company. All rights reserved.
    [Show full text]
  • File Permissions Do Not Restrict Root
    Filesystem Security 1 General Principles • Files and folders are managed • A file handle provides an by the operating system opaque identifier for a • Applications, including shells, file/folder access files through an API • File operations • Access control entry (ACE) – Open file: returns file handle – Allow/deny a certain type of – Read/write/execute file access to a file/folder by – Close file: invalidates file user/group handle • Access control list (ACL) • Hierarchical file organization – Collection of ACEs for a – Tree (Windows) file/folder – DAG (Linux) 2 Discretionary Access Control (DAC) • Users can protect what they own – The owner may grant access to others – The owner may define the type of access (read/write/execute) given to others • DAC is the standard model used in operating systems • Mandatory Access Control (MAC) – Alternative model not covered in this lecture – Multiple levels of security for users and documents – Read down and write up principles 3 Closed vs. Open Policy Closed policy Open Policy – Also called “default secure” • Deny Tom read access to “foo” • Give Tom read access to “foo” • Deny Bob r/w access to “bar” • Give Bob r/w access to “bar • Tom: I would like to read “foo” • Tom: I would like to read “foo” – Access denied – Access allowed • Tom: I would like to read “bar” • Tom: I would like to read “bar” – Access allowed – Access denied 4 Closed Policy with Negative Authorizations and Deny Priority • Give Tom r/w access to “bar” • Deny Tom write access to “bar” • Tom: I would like to read “bar” – Access
    [Show full text]
  • Files and Processes (Review)
    Files and Processes (review) Files and Processes (review) 1/61 Learning Objectives Files and Processes (review) I Review of files in standard C versus using system call interface for files I Review of buffering concepts I Review of process memory model I Review of bootup sequence in Linux and Microsoft Windows I Review of basic system calls under Linux: fork, exec, wait, exit, sleep, alarm, kill, signal I Review of similar basic system calls under MS Windows 2/61 Files Files and I Recall how we write a file copy program in standard C. Processes (review) #include <stdio.h> FILE *fopen(const char *path, const char *mode); size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream); size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream); int fclose(FILE *fp); I We can also use character-based functions such as: #include <stdio.h> int fgetc(FILE *stream); int fputc(int c, FILE *stream); I With either approach, we can write a C program that will work on any operating system as it is in standard C. 3/61 Standard C File Copy Files and Processes (review) I Uses fread and fwrite. I files-processes/stdc-mycp.c 4/61 POSIX/Unix Files Files and Processes (review) I "On a UNIX system, everything is a file; if something is not a file, it is a process." I A directory is just a file containing names of other files. I Programs, services, texts, images, and so forth, are all files. I Input and output devices, and generally all devices, are considered to be files.
    [Show full text]
  • The Application of File Identification, Validation, and Characterization Tools in Digital Curation
    THE APPLICATION OF FILE IDENTIFICATION, VALIDATION, AND CHARACTERIZATION TOOLS IN DIGITAL CURATION BY KEVIN MICHAEL FORD THESIS Submitted in partial fulfillment of the requirements for the degree of Master of Science in Library and Information Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2011 Urbana, Illinois Advisers: Research Assistant Professor Melissa Cragin Assistant Professor Jerome McDonough ABSTRACT File format identification, characterization, and validation are considered essential processes for digital preservation and, by extension, long-term data curation. These actions are performed on data objects by humans or computers, in an attempt to identify the type of a given file, derive characterizing information that is specific to the file, and validate that the given file conforms to its type specification. The present research reviews the literature surrounding these digital preservation activities, including their theoretical basis and the publications that accompanied the formal release of tools and services designed in response to their theoretical foundation. It also reports the results from extensive tests designed to evaluate the coverage of some of the software tools developed to perform file format identification, characterization, and validation actions. Tests of these tools demonstrate that more work is needed – particularly in terms of scalable solutions – to address the expanse of digital data to be preserved and curated. The breadth of file types these tools are anticipated to handle is so great as to call into question whether a scalable solution is feasible, and, more broadly, whether such efforts will offer a meaningful return on investment. Also, these tools, which serve to provide a type of baseline reading of a file in a repository, can be easily tricked.
    [Show full text]
  • Interesting Things You Didn't Know You Could Do With
    Interesting Things You Didn’t Know You Could Do With ZFS Allan Jude -- ScaleEngine Inc. [email protected] twitter: @allanjude Introduction Allan Jude ● 13 Years as FreeBSD Server Admin ● FreeBSD src/doc committer (focus: ZFS, bhyve, ucl, xo) ● Co-Author of “FreeBSD Mastery: ZFS” and upcoming “FreeBSD Mastery: Advanced ZFS” with M. W. Lucas ● Architect of the ScaleEngine CDN (HTTP and Video) ● Host of BSDNow.tv & TechSNAP.tv Podcasts ● Use ZFS for large collections of videos, extremely large website caches, mirrors of PC-BSD pkgs and RaspBSD ● Single Handedly Manage Over 1000TB of ZFS Storage The Power of ZFS ● Integrated Redundancy (Mirroring, RAID-Z) ● Data Integrity Checking (Checksums, Scrub) ● Pooled Storage (Hot Add Disks) ● Multi-Level Cache (ARC, L2ARC, SLOG) ● Copy-on-Write (no fsck) ● Snapshots and Clones ● Quotas and Reservations ● Transparent Compression (LZ4, GZIP1-9) ● Incremental Replication (zfs send/recv) ● Datasets with Individual Inherited Properties ● Custom Properties ● Fine Grained Delegation Applying That Power ZFS has many features, but how can I use them to solve my problems? ZFS has a very well designed command line user interface, making it very easy for a sysadmin to perform common tasks (add more storage, create new datasets, change settings and properties), accomplish things that were not possible before, as well as extract a great deal more information from the storage system. ZFS Was Meant To Be Scripted # zfs list -Hp -r -o name,refer,logicalreferenced sestore5/mysql02 22001288628 24331078144 sestore5/omicron
    [Show full text]
  • If You Have Attempted to Upload Your Files and You Receive an Error Or
    If you have attempted to upload your files and you receive an error or they simply will not upload to EDJOIN, your files are probably either in an inappropriate format, or too large. Please ensure that your document meets the appropriate format and size requirements below. Acceptable format: .PDF Size limit: Each file must not exceed 1 MB (megabyte) or 1024 KB File Name: The file name must contain less than 50 characters including spaces. If the file name contains more than 50 characters or any special characters, you may have trouble attaching your documents and/or the district you are applying to may have trouble viewing them. Please make sure your document title only contains letters and numbers. If the document is multiple pages, you may need to scan multiple sections of the document to maintain the 1MB file size allowance. Saving Your Documents to .PDF Format: If Using A PC: Microsoft Word 2007 or later allows you to save a document as .PDF on a PC 1. Open the document from where you have it saved in your computer. 2. Once the document opens in Microsoft Word, go to the File menu at the top left of your Microsoft Word window and click on Save as. 3. Note where you will be saving the document, go to the bottom of the window and select PDF (*.pdf) in the Save as type box. 4. Save and close. If Using A Mac: Using the print dialog box allows you to save just about any document to .PDF format from a Mac 1.
    [Show full text]
  • Chapter 10: File System
    Chapter 10: File System Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne © 2013 Chapter 10: File System File Concept Access Methods Disk and Directory Structure File-System Mounting File Sharing Protection Operating System Concepts – 9th Edition 11.2 Silberschatz, Galvin and Gagne © 2013 Objectives To explain the function of file systems To describe the interfaces to file systems To discuss file-system design tradeoffs, including access methods, file sharing, file locking, and directory structures To explore file-system protection Operating System Concepts – 9th Edition 11.3 Silberschatz, Galvin and Gagne © 2013 File Concept Contiguous logical address space Types: Data numeric character binary Program Contents defined by file’s creator Many types Consider text file, source file, executable file Operating System Concepts – 9th Edition 11.4 Silberschatz, Galvin and Gagne © 2013 File Structure None - sequence of words, bytes Simple record structure Lines Fixed length Variable length Complex Structures Formatted document Relocatable load file Can simulate last two with first method by inserting appropriate control characters Who decides: Operating system Program Operating System Concepts – 9th Edition 11.5 Silberschatz, Galvin and Gagne © 2013 File Attributes Name – only information kept in human-readable form Identifier – unique tag (number) identifies file within file system Type – needed for systems that support different types Location – pointer to file location on device Size
    [Show full text]
  • Sequence Alignment/Map Format Specification
    Sequence Alignment/Map Format Specification The SAM/BAM Format Specification Working Group 3 Jun 2021 The master version of this document can be found at https://github.com/samtools/hts-specs. This printing is version 53752fa from that repository, last modified on the date shown above. 1 The SAM Format Specification SAM stands for Sequence Alignment/Map format. It is a TAB-delimited text format consisting of a header section, which is optional, and an alignment section. If present, the header must be prior to the alignments. Header lines start with `@', while alignment lines do not. Each alignment line has 11 mandatory fields for essential alignment information such as mapping position, and variable number of optional fields for flexible or aligner specific information. This specification is for version 1.6 of the SAM and BAM formats. Each SAM and BAMfilemay optionally specify the version being used via the @HD VN tag. For full version history see Appendix B. Unless explicitly specified elsewhere, all fields are encoded using 7-bit US-ASCII 1 in using the POSIX / C locale. Regular expressions listed use the POSIX / IEEE Std 1003.1 extended syntax. 1.1 An example Suppose we have the following alignment with bases in lowercase clipped from the alignment. Read r001/1 and r001/2 constitute a read pair; r003 is a chimeric read; r004 represents a split alignment. Coor 12345678901234 5678901234567890123456789012345 ref AGCATGTTAGATAA**GATAGCTGTGCTAGTAGGCAGTCAGCGCCAT +r001/1 TTAGATAAAGGATA*CTG +r002 aaaAGATAA*GGATA +r003 gcctaAGCTAA +r004 ATAGCT..............TCAGC -r003 ttagctTAGGC -r001/2 CAGCGGCAT The corresponding SAM format is:2 1Charset ANSI X3.4-1968 as defined in RFC1345.
    [Show full text]
  • Man Pages Section 2 System Calls
    man pages section 2: System Calls Part No: E29032 October 2012 Copyright © 1993, 2012, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS. Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including anyoperating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications.
    [Show full text]
  • Wikipedia: Design of the FAT File System
    Design of the FAT file system A FAT file system is a specific type of computer file system architecture and FAT a family of industry-standard file systems utilizing it. Developer(s) Microsoft, SCP, IBM, [3] The FAT file system is a legacy file system which is simple and robust. It Compaq, Digital offers good performance even in very light-weight implementations, but Research, Novell, cannot deliver the same performance, reliability and scalability as some Caldera modern file systems. It is, however, supported for compatibility reasons by Full name File Allocation Table: nearly all currently developed operating systems for personal computers and FAT12 (12- many home computers, mobile devices and embedded systems, and thus is a bit version), well suited format for data exchange between computers and devices of almost FAT16 (16- any type and age from 1981 through the present. bit versions), Originally designed in 1977 for use on floppy disks, FAT was soon adapted and FAT32 (32-bit version used almost universally on hard disks throughout the DOS and Windows 9x with 28 bits used), eras for two decades. Today, FAT file systems are still commonly found on exFAT (64- floppy disks, USB sticks, flash and other solid-state memory cards and bit versions) modules, and many portable and embedded devices. DCF implements FAT as Introduced 1977 (Standalone the standard file system for digital cameras since 1998.[4] FAT is also utilized Disk BASIC-80) for the EFI system partition (partition type 0xEF) in the boot stage of EFI- FAT12: August 1980 compliant computers. (SCP QDOS) FAT16: August 1984 For floppy disks, FAT has been standardized as ECMA-107[5] and (IBM PC DOS 3.0) ISO/IEC 9293:1994[6] (superseding ISO 9293:1987[7]).
    [Show full text]