700 Part VI . Programming in Linux The (Web server logs)
700 Part VI . Programming in Linux The distinction between kernel and user space is another fundamental feature of the Linux development environment that gives developers considerable flexibility to write almost any code they want with reasonable assurance that if their program crashes, it won t also crash the system. At the same time, the syscall interface that serves as the gateway between user mode and kernel mode code enables user mode programs to access kernel features and services in a safe, controlled manner. Moreover, the kernel can perform tasks that ordinarily might be executed by user space programs without needing a different programming model. For example, if you implement some sort of user space functionality, such as providing a basic HTTP server, in the kernel, the same syscall interface makes it possible to interact with the HTTP server; there is no need to use a new or different programming interface. On the downside, the sharp delineation between kernel and user space creates some disadvantages for normal users. For example, unlike Microsoft Windows, user space programs do not have direct access to hardware devices. For user space programs to access a sound card, for example, the system administrator must take steps to permit this sort of access. However, this is a small inconvenience compared to the increased stability for which Linux systems are known. The Security Model As you learned earlier in this book, all users are not created equal. Some users, like the root user, are effectively omnipotent and can do anything on a system. Most users have more limited access. The user (and group) IDs of these less privileged users control what programs they can execute and the files they can access. The same restrictions apply to the development environment. For example, if you write a program, you might not be able to access a certain feature, such as locking memory with the mmap() system call, unless your program runs with root permissions. If your program creates files, the default file permissions are controlled by the umask of the user executing the program and/or a umask that you might specifically set at runtime using the umask() system call. Naturally, your program cannot create, delete, or modify files or directories if it doesn t have the necessary privileges. The Linux development environment also makes it possible for a program to drop or add privileges at runtime by calling functions that change its UID or GID. The impact of the Linux security model on programming is twofold. First, the same rules and restrictions that affect running programs and other elements of normal system usage also affect the process of creating programs and what those programs can do. This effect is no more than the logical consequence of the Linux security model itself. Programmatically, however, you have more ways, or perhaps more finely-grained ways, to interact with the security subsystem than you do as a normal user of the system. The second effect of the Linux security model for programmers is that writing a program imposes significant burdens on programmers to program securely. An e-mail program, for example, that stores usernames and passwords in a text file that is unencrypted and/or world-readable is just as insecure as a program that fails to check user input for buffer overflow. To use a subtler example, when faced with a
From our experience, we can recommend PHP Web Hosting services, if you need affordable webhost to host and run your web application.