|
|
HP-UX Reference > Cchatr_pa(1)PA-RISC Systems OnlyHP-UX 11i Version 2: December 2007 Update |
|
NAMEchatr_pa: chatr — change program's internal attributes on PA-RISC systems SYNOPSISPA-RISC 32-bit SOM chatrchatr [-nqsMN [z|Z]] [-l library] [-B mode] [+b flag] [+dbg flag] [+es flag] [+mergeseg flag] [+gst flag] [+gstbuckets size] [+gstsize size] [+k flag] [+l library] [+mem_check flag] [+pd size] [+pi size] [+plabel_cache flag] [+q3p flag] [+q4p flag] [+r flag] [+s flag] [+z flag] file ... PA-RISC 64-bit ELF chatrThere are two possible syntactic forms that can be used to invoke PA-RISC 64-bit chatr. FORMAT 1: The first syntactic form, which is compatible with the SOM chatr, is used for backward compatibility, and for easy manipulation of ordinary files that only have a single text and a single data segment: chatr [-nqszZ] [-l library] [-B mode] [+b flag] [+cd flag] [+ci flag] [+es flag] [+gst flag] [+gstsize size] [+k flag] [+l library] [+md flag] [+mem_check flag] [+mi flag] [+pd size] [+pi size] [+s flag] [+z flag] file ... FORMAT 2: The second syntactic form provides the ability to explicitly specify segments to be modified: chatr [-s] [-B mode] [+c flag] [+dz flag] [+k flag] [+m flag] [+p size] [+r flag] [+s flag] [+si index | +sa address | +sall ] [+z flag] file ... RemarksThis manpage describes chatr on PA-RISC systems. For chatr on Integrity systems, see chatr_ia(1). DESCRIPTIONchatr allows you to change a program's internal attributes for 32-bit mode SOM and 64-bit mode ELF files. Upon completion, chatr prints the file's old and new values to standard output unless -s is specified. The +pd and +pi options only provide a hint for the virtual memory page size. The actual page sizes may vary. Under certain conditions, page size hints of L may result in better performance, depending on the specific memory requirements of the application. The performance of some applications may benefit from static branch prediction, others may not. The +r option provides a hint for using or avoiding this feature. The +gst and related options provide performance enhancements through use of global symbol table which improves searching for exported symbols. See dld.sl(5) and the HP-UX Linker and Libraries Online User Guide for more information. Common Options For PA-RISC 32-bit SOM And PA-RISC 64-bit ELF (FORMAT 1) chatrchatr, by default, prints each file's magic number and file attributes to the standard output.
Options For PA-RISC 32-bit SOM chatr Only
Options For PA-RISC 64-bit ELF chatrPA-RISC 64-bit ELF chatr is similar to SOM chatr but supports new options (and obsoletes others). New options: OPTIONS FOR PA-RISC 64-bit ELF chatr (FORMAT 1)
OPTIONS FOR PA-RISC 64-bit ELF chatr (FORMAT 2) With common options: -s, -B mode, +k flag, +r flag, +s flag, +z flag.
chatr and MAGIC NumbersThe term shared applies to the magic number SHARE_MAGIC while the term demand-loaded applies to the magic number DEMAND_MAGIC. See magic(4) and the HP-UX Linker and Libraries Online User Guide for more information. chatr labels the following type of executables in output.
The linker produces SHARE_MAGIC executables by default. Using SHMEM_MAGICSHMEM_MAGIC is an interim solution until 64-bit addressability is available with a true 64-bit kernel. SHMEM_MAGIC will not be supported on future HP implementations of 64-bit architectures (beyond PA-RISC 2.0). Programs that need larger than 1.75 GB of shared memory on those architectures will have to be recompiled (as 64-bit executables) for those architectures. Programs that are compiled as 64-bit executables on any 64-bit HP implementation (including PA-RISC 2.0) cannot be marked as SHMEM_MAGIC nor do they need to be as they will already have access to more than 1.75 GB of shared memory. The additional 1 GB of shared memory that is available over other types of executables can be availed of only for system V shared memory and not other forms of shared memory (like memory mapped files). Large Private Data SpaceStarting from the 11i release of HP-UX, an additional 1 to 2GB of private address space is made available for 32-bit programs (if enabled on a per process basis), at the expense of shared memory address space. This change increases the amount of private data space available for a process. Two new options, +q3p and +q4p, have been added to the chatr command that allow the user to control whether the 3rd quadrant (the 1GB of address space from 0x80000000-0xBFFFFFFF) and the 4th quadrant (the 1GB of address space from 0xC0000000-0xFFFFFFFF) of a process are part of the processes private address space or are shared with other running processes. Previously, the 3rd and 4th quadrants were dedicated for shared object usage. For example, System V shared memory and memory mapped files using a shared mapping (MAP_SHARED). In order to use this new feature, the maxdsiz kernel configurable variable will need to be increased appropriately; see maxdsiz(5). Also, the system will have to enable enough swap space to support processes with large private address spaces. Compatibility issuesProcesses that enable a private 3rd quadrant (q3p processes) will reduce the amount of address space available for shared objects by 1GB. Also, q3p processes will not be able to share objects that were created by another, non-q3p process, even in the 4th quadrant, unless those objects were created by the non-q3p process using the IPC_GLOBAL flag (System V shared memory) or MAP_GLOBALflag (mmap). If recompiling is not an option, it will be necessary to make all processes that share objects with the q3p process into q3p processes (chatr +q3p enable a.out). Processes that enable a private 4th quadrant (q4p processes) will have no address space available for shared objects. This means that the process will not be able to use System V shared memory, shared mapped files, etc. Shared libraries will still work, although the kernel will map them as private. Note that a q4p process implies that the 3rd quadrant is private also. In other words, the kernel will not execute a process that only enables a private 4th quadrant. Because the system call gateway page has to remain at address 0xC0000000 for binary compatibility reasons, the data segment cannot be extended past the beginning of the 4th quadrant. Therefore, the brk() and sbrk() system calls will only allow the data segment to be expanded up to that address. To take advantage of private address space in the 4th quadrant, memory will need to be allocated using the mmap() system call with the MAP_PRIVATE option. The system call malloc() has been modified to do this automatically. No re-link will be necessary to take advantage of the new malloc() for a program that uses a shared version of the C library. A program that was linked with a non-shared library version of the C library, however, will need to be re-linked. These changes have no compatibility impacts if the feature is not enabled. This feature can only be enabled for 32-bit programs running on the 64-bit version of HP-UX. The 32-bit version of HP-UX will silently ignore the request for a private 3rd or 4th quadrant. Restricting Execute Permission on StacksA frequent or common method of breaking into systems is by maliciously overflowing buffers on a program's stack, such as passing unusually long, carefully chosen command line arguments to a privileged program that does not expect them. Malicious unprivileged users can use this technique to trick a privileged program into starting a superuser shell for them, or to perform similar unauthorized actions. One simple yet highly effective way to reduce the risk from this type of attack is to remove the execute permission from a program's stack pages. This improves system security without sacrificing performance and has no negative effects on the vast majority of legitimate applications. The changes described in this section only affect the very small number of programs that try to execute (or are tricked into executing) instructions located on the program's stack(s). If the stack protection feature described in this section is enabled for a program and that program attempts to execute code from its stack(s), the HP-UX kernel will terminate the program with a SIGKILL signal, display a message referring to this manual page section, and log an error message to the system message log (use dmesg to view the error message). The message logged by the kernel is:
If you see one of these messages, check with the program's owner to determine whether this program is legitimately executing code from its stack. If it is, you can use one or both of the methods described below to make the program functional again. If the program is not legitimately executing code from its stack, you should suspect malicious activity and take appropriate action. HP-UX provides two options to permit legitimate execution from a program's stack(s). Combinations of these two options help make site-specific tradeoffs between security and compatibility. The first method is the use of the +es option of chatr and affects individual programs. It is typically used to specify that a particular binary must be able to execute from its stack, regardless of the system default setting. This allows a restrictive system default while not preventing legitimate programs from executing code on their stack(s). Ideally this option should be set (if needed) by the program's provider, to minimize the need for manual intervention by whomever installs the program. An alternate method is setting the kernel tunable parameter, executable_stack, to set a system-wide default for whether stacks are executable. Setting the executable_stack parameter to 1 (one) with sam (see sam(1M)) tells the HP-UX kernel not to execute protect program stack(s). This is the preferred setting if compatibility with older releases is more important than security. Setting it to a 0 (zero) is appropriate if security is more important than compatibility. This is the recommended setting, because it significantly improves system security with minimal, if any, negative effects on legitimate applications. Combinations of these settings may be appropriate for many applications. For example, after setting executable_stack to 0, you may find that one or two critical applications no longer work because they have a legitimate need to execute from their stack(s). Programs such as simulators or interpreters that use self-modifying code are examples you might encounter. To obtain the security benefits of a restrictive system default while still letting these specific applications run correctly, set executable_stack to 0, and run chatr +es enable on the specific binaries that need to execute code from their stack(s). These binaries can be easily identified when they are executed, because they will print error messages referring to this manual page. The possible settings for executable_stack are as follows:
The table below summarizes the results from using the possible combinations of chatr +es and executable_stack when executing from the program's stack. Running chatr +es disable relies solely on the setting of the executable_stack kernel tunable parameter when deciding whether or not to grant execute permission for stacks and is equivalent to not having run chatr +es on the binary.
RETURN VALUEchatr returns zero on success. If the command line contents is syntactically incorrect, or one or more of the specified files cannot be acted upon, chatr returns information about the files whose attributes could not be modified. If no files are specified, chatr returns decimal 255. Illegal optionsFor PA-RISC 32-bit chatr, if you use an illegal option, chatr returns the number of words in the command line. For example,
For PA-RISC 64-bit chatr, if you use an illegal option, chatr returns the number of non-option words present after the first illegal option.
Invalid argumentsIf you use an invalid argument with a valid option and you do not specify a file name, both PA-RISC 32-bit and 64-bit chatr return 0.
For PA-RISC 32-bit chatr, if you specify a file name (regardless of whether or not the file exists), chatr returns number of words in the command line.
For PA-RISC 64-bit chatr, if you specify a file name (regardless of whether or not the file exists), chatr returns the number of files specified.
Invalid filesFor both PA-RISC 32-bit and 64-bit chatr, if the command cannot act on any of the files given, it returns the total number of files specified (if some option is specified). Otherwise it returns the number of files upon which it could not act.
EXTERNAL INFLUENCESEnvironment VariablesThe following internationalization variables affect the execution of chatr:
If any internationalization variable contains an invalid setting, chatr behaves as if all internationalization variables are set to C. See environ(5). In addition, the following environment variable affects chatr:
EXAMPLESChange a.out to demand-loaded chatr -q a.out Change binding mode of program file that uses shared libraries to immediate and nonfatal. Also enable usage of SHLIB_PATH environment variable: chatr -B immediate -B nonfatal +s enable a.out Disallow run-time path lookup for the shared library /usr/lib/libc.sl that the shared library libfoo.sl depends on: chatr +l /usr/lib/libc.sl libfoo.sl Given segment index number 5 from a previous run of chatr, change the page size to 4 kilobytes: chatr +si 5 +p 4K average64 SEE ALSOMiscellaneous
Texts and Tutorials
|
|