5.1.3.6 binfmt_misc
binfmt_misc provides the ability to register additional binary formats to the kernel without compiling an
additional module or kernel. Therefore, binfmt_misc needs to know magic numbers at the beginning, or the
filename extension of the binary.
binfmt_misc works by maintaining a linked list of structs that contain a description of a binary format,
including a magic number with size, or the filename extension, offset and mask, and the interpreter name. On
request it invokes the given interpreter with the original program as an argument. Because binfmt_misc does
not define any default binary-formats, one has to register an additional binary-format. Because files in
/proc/sys/binfmt_misc are not real disk-based files with user data, there is no object reuse issue.
Refer to kernel-2.6.18/linux-2.6.18/Documentation/binfmt_misc.txt for a detailed
specification of binfmt_misc.
5.1.3.7 securityfs
Linux Security Modules (LSMs) use securityfs, which is a new virtual file system, avoiding some of the other
LSMs to create their own file systems. securityfs must be mounted on /sys/kernel/security. To
users it appears to be part of the sysfs, but it is a new and distinct one.
5.1.3.8 configfs
configfs is a RAM-based pseudo file system manager of kernel objects. It provides a converse of sysfs
functionality through a user space driver kernel object configuration. For additional information about
configfs, refer to http://lwn.net/Articles/148973 and http://lwn.net/Articles/149005.
5.1.4 inotify
inotify is a mechanism for watching and communicating file system events to user space. It is an
improvement and replacement of the dnotify tool, which had the same purpose. inotify is relevant because
different sorts of applications might want or need to know when events such as file changes or creation
happen. An example of the use of inotify is with security monitoring applications that must know of, and can
benefit from being told about, file system changes.
inotify uses a syscall interface. Applications open a watch file descriptor via the inotify_init() call
and register watches via the inotify_add_watch() call. To add a watch, an application must have
DAC read permission on the inode. The access checks are performed by the vfs_permission()
function. For more information on inotify, see the inotify(7) manage,
Documentation/filesystems/inotify.txt in the SLES kernel source available.
5.1.5 Discretionary Access Control (DAC)
Previous sections have described how appropriate *_permission() functions are called to perform access
checks for non-disk-based and disk-based file systems. Access checks are based on the credentials of the
process attempting access, and access rights assigned to the object.
When a file system object is created, the creator becomes the owner of the object. The group ownership
(group ID) of the object is set either to the effective group ID of the creator, or to the group ID of the parent
directory, depending on the mount options and the mode of the parent directory.
If the file system is mounted with the grpid option, then the object takes the group ID of the directory in
which it is created; otherwise, by default, the object takes the effective group ID of the creator, unless the
directory has the setgid bit set, in which case the object takes the GID from the parent directory, and also gets
the setgid bit set if it is a directory itself. This ownership can be transferred to another user by invoking the
46