Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to learn shell script". In daily operation, I believe many people have doubts about how to learn shell script well. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to learn shell script well". Next, please follow the editor to study!

Chapter XIV shell portability issues and extensions

You can read through this article first.

If you want to write a good portable shell, you should not only understand the differences between various shell versions, but also have a lot of programming skills, such as trying to get the information you need from environment variables.

Chapter 15 secure shell script: starting Point

Tips for security shell scripts:

1. Do not place the current directory (period) under PATH. Executable programs should only be placed in a standard system directory, and putting the current directory in PATH is undoubtedly opening the door to a Trojan horse (Trojan Horse).

2. Set protection for the bin directory. Make sure that each directory under $PATH can only be written to by its owner, and no one else can. The same principle should also be applied to all programs in the bin directory.

3. Before you write the program, you want to clear it. Take some time to think about what you are going to do and how to do it. Don't write on the text editor in the first place. Elegant handling of errors and failures should also be designed in the program.

4. All input parameters should be checked for validity. If you expect a number, verify that it is a number and is within the required range. Other needs are tested in the same way.

5. Check the error handling code for all commands that can return errors. A failure that is not what you expect is likely to be a problematic forced failure that leads to improper behavior in the script. For example, if the parameter is NFS to load disk or character-oriented device files, even executing as root may cause some commands to fail.

6. Don't trust incoming environment variables. If they are used by subsequent commands (such as TZ, PATH, IFS, and so on), check and reset to known values. In any case, the best way is to explicitly set what you need (for example, PATH contains only the system bin directory, set IFS to the space locator and line feeds).

7. Start from a known place. At the beginning of the script, exactly cd to the known directory so that any relative path names can then be pointed to the known location. Confirm that the cd operation is successful: cd app-dir | | exit 1

Use syslog (8) to keep the audit trail. Record the date and time of the reference, username, etc., see the user manual of logger (1). If there is no logger, you can set up a function to keep the log file:

The code is as follows:

Logger () {

Printf "% s\ n"$*" > > / var/adm/logsysfile

}

Logger "Run by user" $(id-un) "($USER) at" $(/ bin/date)

9. When using this input, be sure to reference the user input. For example: "$1" and "$*", this prevents malicious users from entering out-of-range calculations and execution.

10. Do not use eval on user input. Even after referencing user input, do not use eval to hand it over to shell for processing. If the user reads your script and finds that you are using eval, you can easily use the script to do any damage.

11. Reference the result of wildcard expansion. You can put spaces, semicolons, backslashes, etc., in the file name and leave the tricky things to the system administrator. If the managed script does not reference the file name parameter, this script will cause problems with the system.

12. Check whether the user input has meta characters. If you use eval or $(...) Check to see if there are meta characters like $or `.

13. Test your code and read it carefully. Look for loopholes and errors that can be exploited. Take all the bad ideas into account, study your code carefully, try to find ways to destroy it, and then correct the problems found.

14. Watch out for competitive conditions (race condition). Is it possible for an attacker to execute arbitrary commands between any two commands in your script? is this harmful to security? If so, deal with your script in a different way.

15. Be suspicious of symbolic connections. When you chmod a file or edit a file, check to see if it is really a file, rather than a symbolic connection to a critical system file (use [- L file] or [- h file] to detect whether file is a symbolic connection.

16. Find someone else to re-check your program to see if there is a problem.

17. Use setgid instead of setuid whenever possible. These terms will be discussed later, which simply means that using setgid can limit the scope of damage to a group.

18. Use new users instead of root. If you have to use setuid to access a set of files, consider creating a new user, a non-root user to do this and set the setuid to him.

19. Limit code that uses setuid as much as possible. Minimize setuid code as much as possible. Move it to a separate program and then reference it only when needed in a large script. In any case, please protect the code as if the script can be referenced by anyone, anywhere.

20. Prologue to a secure shell:

The code is as follows:

IFS='\ t\ n'# I have seen it many times before

Unset-f unalias # ensures that unalias is not a function

\ unalias-a # unset all aliases and quote unalias so it's not alias-expanded

Unset-f command # ensures that the command is not called as a function

# get a reliable path prefix to deal with situations where getconf is not available.

# get a reliable path prefix,handling case where getconf is not 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, which need to be noted.

The book ends with an introduction to how to write your own shell program manual, and unix files and file systems. So far, the book has been read through.

At this point, the study of "how to learn shell script well" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.