Shell Scripting Learning Guide [VI] (Arnold Robbins & Nelson h.f Beebe) _linux Shell

Learn Shell to now, always thought that they will not commit a very two problems, the result of this book last time made a very 2, integrity not protect AH!!! I'm under the test file path except wildcard * and? What can be used outside the same thing, the result of the $home under the implementation of RM. All right, the egg hurts for the whole afternoon! Return the wood to any one of the configuration files. Warn posterity, do not use RM Test wildcard! Use rm! at any time with care

14th Shell portability issues and extensions

You can read through this article first.
To write a good portable shell, not only to understand the differences between the various shell versions, but also have a lot of programming skills, such as as far as possible from the environment variables to obtain the required information.

15th Chapter Secure Shell script: starting point

Tips for security shell scripting:
1, do not put the current directory (point number) under the path. Executable programs should only be placed in the standard system directory, the current directory in the path, is undoubtedly open the Trojan Horse (Trojan horse) door.
2, for the Bin directory settings protection. Make sure that each directory under $path is written only by its owner, and no one else can. The use of a kind of truth should also be applied to all the programs in the Bin directory.
3, before writing the program, want to clear first. Take the time to think about what you want to do and how to do it. Don't write on the text editor from the beginning. The graceful handling of errors and failures should also be designed in the program.
4. The validity of all input parameters should be checked. If you expect a number, verify that it is a number and that it is within the range of requirements. Other needs are tested in this way.
5. For all commands that can return an error, check the error handling code. Failure in your expectation is likely to be a problem of forced failure, resulting in improper behavior of the script. For example, if the parameter is an NFS-loaded disk or a character-oriented device file, even executing as root may cause some commands to fail.
6, do not trust the incoming environment variables. If they are used by the next command (such as TZ, PATH, IFS, and so on), check and reset to a known value. In any case, the best way is to explicitly set what you want (for example, path contains only the system bin directory, and the IFS is a space locator and line break).
7. Start from a known place. At the beginning of the script, the exact CD is to a known directory, so that any subsequent relative path names can point to a known location. Confirm CD Operation successful: cd App-dir | | Exit 1
8, the use of syslog (8) to maintain audit trails. Record the date and time of the reference, username, and so on, and see the Manual for the use of logger (1). If there is no logger, you can create a function to keep the log file:

Copy Code code as follows:

Logger () {
printf "%s\n" "$*" >>/var/adm/logsysfile
}
Logger "Run by User" $ (id-un) "($USER) at" $ (/bin/date)

9. When you use this input, you must refer to the user input. For example: "$" and "$*", this will prevent malicious user input beyond the scope of the calculation and execution.
10. Do not use eval on user input. Even after referencing user input, do not use eval to give it to the shell for reprocessing. If the user reads your script and finds that you use eval, you can easily use the script to do any damage.
11, the result of referencing the expansion of the wildcard character. You can put a space, a semicolon, a backslash, and so on in the filename, so that the tricky things to the system administrator to deal with. If the managed script does not refer to the filename parameter, this script will cause a system problem.
12, check whether the user entered a meta character. If you use eval or $ (...) , check to see if there are any meta characters such as $ or '.
13, check your code, and carefully read it. Find out if there are vulnerabilities and errors that can be exploited. Take all the bad ideas into consideration, study your code carefully, try to figure out how to destroy it, and then fix the problem.
14. Pay attention to competitive conditions (race condition) is it possible for an attacker to execute arbitrary commands between any two commands in your script, which is dangerous to security? If so, deal with your script in a different way.
15, the symbolic connection is doubtful. When chmod a file or edit a file, check that it is really a file, not a symbolic connection to a critical system file (using [-L file] or [-H-file] to detect whether file is a symbolic connection.
16, find someone else to re-examine your program to see if there is a problem.
17, as far as possible with setgid and not with setuid. These terms are discussed later, Jianzhi is the use of setgid to limit the damage to a group.
18, use the new user instead of root. If you must use SETUID to access a group of files, please consider setting up a new user, not the root user to do this and set setuid to him.
19, limit the use of setuid code as much as possible. Make the setuid code as minimal as possible. Move it to a separate program, and then refer to it when needed in a large script. In any case, do code protection as if the script could be referenced anywhere by anyone.
20, a security Shell's opening line:

Copy Code code as follows:

ifs= ' \t\n ' #Seen many times before
Unset-f Unalias #Ensure that unalias is not a function
\ unalias-a #unset all aliases and quote Unalias so it's not alias-expanded
Unset-f Command #Ensure that the command that is called is not a function
#Get reliable path prefix
to deal with getconf unavailable conditions.
#get a reliable path prefix,handling case where getconf isn't available.
Syspath= "$ (command-p getconf PATH 2>/dev/null))"
if [[Z "$SYSPATH"]];then
Syspath= "/usr/bin:/bin"
Fi
Path= "$SYSPATH: $PATH"

This code uses a number of non-POSIX extensions that need to be noted.

The book concludes with a description of how to write your own shell program, manual, and UNIX file and file systems. The book is read through.