IBM 10 SP1 EAL4 Manual Do Utilizador
5.1.1.3 write()
Another example of a file system operation is a write() system call to write to a file that was opened for
writing. The write() system call in VFS is very straightforward, because access checks have already been
performed by open(). The following list shows the call sequence of a write() call:
1. Call the write() system call with the file descriptor that was returned by open().
2. Call fget() to get the file pointer corresponding to the file descriptor.
3. If the file operation vector of the file pointer is set, use the inode operation vector to call the disk-
2. Call fget() to get the file pointer corresponding to the file descriptor.
3. If the file operation vector of the file pointer is set, use the inode operation vector to call the disk-
based file system’s write() routine of the disk-based file system.
5.1.1.4 mount()
An administrator mounts file systems using the mount() system call. The mount() system call provides
the kernel with the following:
●
the file system type
●
the pathname of the mount point
●
the pathname of the block device that contains the file system
●
the flags that control the behavior of the mounted file system
●
a pointer to a file system dependent data structure (that may be NULL).
For each mount operation, the kernel saves the mount point and the mount flags in mounted file system
descriptors. Each mounted file system descriptor is a vfsmount type of data structure. The
sys_mount() function in the kernel copies the value of the parameters into temporary kernel buffers,
descriptors. Each mounted file system descriptor is a vfsmount type of data structure. The
sys_mount() function in the kernel copies the value of the parameters into temporary kernel buffers,
acquires the big kernel lock, and invokes the do_mount() function to perform the mount.
There are no object reuse issues to handle during file system mounting because the data structures created are
not directly accessible to user processes. However, there are security-relevant mount flags that affect access
control. Following are the security-relevant mount flags and their implications for access control.
There are no object reuse issues to handle during file system mounting because the data structures created are
not directly accessible to user processes. However, there are security-relevant mount flags that affect access
control. Following are the security-relevant mount flags and their implications for access control.
•
MS_RDONLY: The file system is mounted in read-only mode. Write operations are prohibited for all
files regardless of their mode bits.
•
MS_NOSUID: the kernel ignores suid and sgid bits on executables when executing files from this file
system.
•
MS_NODEV: Device access to a character or block device is not permitted from files on this file
system.
•
MS_NOEXEC: Execution of any programs from this file system is not permitted, even if the execute
bit is set for the program binary.
•
MS_POSIXACL: Indicates if ACLs on files on this file system are to be honored or ignored.
5.1.1.5 Shared subtrees
Shared subtrees have been implemented in VFS. This allows an administrator to configure the way the file
system mounts will coexist in the tree, the relationships between them, and how they propagate in different
namespaces. This increases flexibility in the way namespaces can be populated and presented to users. For
detailed information about the shared-subtree feature, see
system mounts will coexist in the tree, the relationships between them, and how they propagate in different
namespaces. This increases flexibility in the way namespaces can be populated and presented to users. For
detailed information about the shared-subtree feature, see
The shared-subtree feature introduces new types of mounts:
38